[Webkit-unassigned] [Bug 69083] Several CSS lexer rules don't match CSS 2.1 spec

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 26 03:10:52 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=69083





--- Comment #6 from Zoltan Herczeg <zherczeg at webkit.org>  2011-10-26 03:10:51 PST ---
Playing with the CSS tokenizer is quite funny. Although there are several bugs in the tokeinzer, they cannot be exploited because other mechanics hides them.

Yesterday I checked an URI parsing bug. Due to a bug in CSSParser::text(...) the slash-newlines sequences are converted to newline in the same way as '\a' converted to 'a', so they are treated as normal escape sequences. I thought I could exploit this, but I didn't work, since there is another funny CSS rule, which says chars < 32 must be skipped.

So www<tab>.<tab>google<tab>.<tab>com is the same as www.google.com since <tab> is equal to 9, which is less than 32, and discarded. However, www<space>.<space>google<space>.<space>com is different, since <space> is not less than 32. <newline> is equal to 10, so it is discarded as well.

Today I checked this bug:

> Another batch of what are considered control characters.
> 
> > original:
> > unicode        \\{h}{1,6}(\r\n|[ \t\r\n\f])?
> > wk:
> > unicode         \\{h}{1,6}[ \t\r\n\f]?
> > 
> > This can be exploited by a \r\n newline: A\41\r\nB should be "AAB" but it will be "AA" and "B" in WK.
> 
> Seems likely to just be a bug.

Guess what it does not appear as well. Why?

WebCore/xml/MarkupTokenizerBase.h InputStreamPreprocessor::peek(...) converts '\r\n' sequences to '\n'! This function is indirectly called from WebCore/html/parser/HTMLDocumentParser.cpp:267 through m_tokenizer->nextToken(...). Thus, the CSS parser never encounters a '\r\n'.

Although we could simplify the "nl \n|\r\n|\r|\f" rule and CSSParser::text(...), I don't want to do it since I hope they will be dropped in the future as the hand written parser is more than twice as fast.

But I want to add a newline related layout test.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list