Bug 176232 - transformCanLikelyUseFastPath() can read off the end of a string
Summary: transformCanLikelyUseFastPath() can read off the end of a string
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-09-01 10:47 PDT by Simon Fraser (smfr)
Modified: 2017-09-05 08:52 PDT (History)
6 users (show)

See Also:


Attachments
Patch (5.38 KB, patch)
2017-09-01 10:53 PDT, Simon Fraser (smfr)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2017-09-01 10:47:48 PDT
transformCanLikelyUseFastPath() can read off the end of a string
Comment 1 Simon Fraser (smfr) 2017-09-01 10:53:36 PDT
Created attachment 319617 [details]
Patch
Comment 2 Simon Fraser (smfr) 2017-09-01 10:54:01 PDT
rdar://problem/33851237
Comment 3 WebKit Commit Bot 2017-09-01 11:49:05 PDT
Comment on attachment 319617 [details]
Patch

Clearing flags on attachment: 319617

Committed r221488: <http://trac.webkit.org/changeset/221488>
Comment 4 WebKit Commit Bot 2017-09-01 11:49:06 PDT
All reviewed patches have been landed.  Closing bug.
Comment 5 Darin Adler 2017-09-03 17:12:49 PDT
Comment on attachment 319617 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=319617&action=review

> Source/WebCore/ChangeLog:11
> +        Code added in r220382 could read one byte past the end of the string when looking for the 'z'
> +        of a rotateZ() function. The code was actually incorrect, testing for the 'z at i+6 after
> +        already incrementing i by 6. This patch makes the code correctly detect rotateZ().

Is there a test we can write that would have failed before because of the bad "z" check?

> Source/WebCore/css/parser/CSSParserFastPaths.cpp:1271
> -            if (toASCIILower(chars[i + 6]) == 'z')
> +            if (toASCIILower(chars[i]) == 'z')

Not that this tiny bit of efficiency matters, but all of these can be written more efficiently:

    if (isASCIIAlphaCaselessEqual(chars[i], 'z'))

Same applies for all the other checks above.
Comment 6 Simon Fraser (smfr) 2017-09-05 08:52:13 PDT
(In reply to Darin Adler from comment #5)
> Comment on attachment 319617 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=319617&action=review
> 
> > Source/WebCore/ChangeLog:11
> > +        Code added in r220382 could read one byte past the end of the string when looking for the 'z'
> > +        of a rotateZ() function. The code was actually incorrect, testing for the 'z at i+6 after
> > +        already incrementing i by 6. This patch makes the code correctly detect rotateZ().
> 
> Is there a test we can write that would have failed before because of the
> bad "z" check?

No, becuasse we'd just fail the fast parsing and fall back to normal parsing (which is not detectable).

> > Source/WebCore/css/parser/CSSParserFastPaths.cpp:1271
> > -            if (toASCIILower(chars[i + 6]) == 'z')
> > +            if (toASCIILower(chars[i]) == 'z')
> 
> Not that this tiny bit of efficiency matters, but all of these can be
> written more efficiently:
> 
>     if (isASCIIAlphaCaselessEqual(chars[i], 'z'))
> 
> Same applies for all the other checks above.

Good to know, will fix.