Closed
Bug 311157
Opened 19 years ago
Closed 19 years ago
Comment-hiding compromise left E4X parsing/scanning inconsistent
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.8beta5
People
(Reporter: brendan, Assigned: brendan)
References
Details
(Keywords: crash, js1.6, verified1.8)
Attachments
(1 file)
4.14 KB,
patch
|
mrbkap
:
review+
shaver
:
superreview+
asa
:
approval1.8rc1+
|
Details | Diff | Splinter Review |
Given the final state of affairs after bug 311071 was fixed, with XML element and list literals unambiguous in all script tags (with or without e4x=1 or a new MIME type), but XML comment and CDATA literals not supported because they're ambiguous with HTML comment hiding hacks, there are some holes in the parser/scanner state space. For example, x = <hi> <!-- duh --> there </hi>; should work in a script tag, but it does not. An assertion in jsparse.c fires and a bad parse tree is constructed, leading to a crash. The problem is that the scanner collects the space before the <!-- and stops on the <, thinking it will be tokenized as an XML token (start-tag opener, etc.). But thanks to the comment hiding hack support, it's skipped (characters to end of line are eaten). That means the next token is not something to-do with <, but a TOK_NAME for 'there'. The code in XMLElementContent in jsparse.c asserts otherwise, then blithely makes a parse node assuming it got the expected type (one of TOK_XMLPI, TOK_XMLCDATA, and TOK_XMLCOMMENT). For TOK_NAME, this is safe, but not so for other token types. The straightforward fix is to toggle JSOPTION_XML when parsing XMLElementContent (easy to do, restores the previous coupling between the TSF_XMLTEXTMODE scanner subset and the comment-hiding hack, by enabling the latter when using the former to scan text up to a < in a tag). /be
Assignee | ||
Comment 1•19 years ago
|
||
Should fix for RC1, not a 1.8b5 stopper. Potential for security exploit low but non-zero given content-controlled parse tree type botch. /be
Assignee | ||
Comment 2•19 years ago
|
||
Straighforward refactoring to consolidate JSOPTION_XML toggling and avoid doing it when recursing through XMLElementOrList or XMLElementContent. /be
Assignee | ||
Updated•19 years ago
|
Attachment #198546 -
Flags: superreview?(shaver)
Attachment #198546 -
Flags: review?(mrbkap)
Comment 3•19 years ago
|
||
Comment on attachment 198546 [details] [diff] [review] proposed fix r=mrbkap
Attachment #198546 -
Flags: review?(mrbkap) → review+
Comment on attachment 198546 [details] [diff] [review] proposed fix sr=shaver
Attachment #198546 -
Flags: superreview?(shaver) → superreview+
Assignee | ||
Comment 5•19 years ago
|
||
Fixed on the trunk. /be
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Flags: blocking1.8rc1+
Resolution: --- → FIXED
Assignee | ||
Comment 6•19 years ago
|
||
Comment on attachment 198546 [details] [diff] [review] proposed fix This is a necessary fix to restore lost consistency between the scanner and the parser. /be
Attachment #198546 -
Flags: approval1.8rc1?
Comment 7•19 years ago
|
||
RCS file: /cvsroot/mozilla/js/tests/e4x/Expressions/11.4.1-04.js,v done Checking in 11.4.1-04.js; /cvsroot/mozilla/js/tests/e4x/Expressions/11.4.1-04.js,v <-- 11.4.1-04.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/js/tests/e4x/Expressions/11.4.1-05.js,v done Checking in 11.4.1-05.js; /cvsroot/mozilla/js/tests/e4x/Expressions/11.4.1-05.js,v <-- 11.4.1-05.js initial revision: 1.1 done
Flags: testcase+
Comment 8•19 years ago
|
||
Checking in regress-311157-01.js; /cvsroot/mozilla/js/tests/js1_6/Regress/regress-311157-01.js,v <-- regress-311157-01.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/js/tests/js1_6/Regress/regress-311157-02.js,v done Checking in regress-311157-02.js; /cvsroot/mozilla/js/tests/js1_6/Regress/regress-311157-02.js,v <-- regress-311157-02.js initial revision: 1.1 done
Updated•19 years ago
|
Attachment #198546 -
Flags: approval1.8rc1? → approval1.8rc1+
Comment 10•19 years ago
|
||
So lemme get this straight. All XML comments and CDATA tags are ignored when the MIME type doesn't have e4x=1. Everything else works regardless of whether e4x=1. Is that correct? Are there any cases in which XML comments are parsed without e4x=1?
Assignee | ||
Comment 11•19 years ago
|
||
(In reply to comment #10) > So lemme get this straight. All XML comments and CDATA tags are ignored when the > MIME type doesn't have e4x=1. No, only top-level ones. > Are there any cases in which XML comments are parsed without e4x=1? Yes, if they're contained in a list or element. Same for CDATA. /be
Comment 13•18 years ago
|
||
verified fixed 1.9 windows/mac(ppc|tel)/linux 20060812
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•