Bug 30656 - Fix calculation of length in WebSocketChannel.cpp
Summary: Fix calculation of length in WebSocketChannel.cpp
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-21 18:42 PDT by Fumitoshi Ukai
Modified: 2009-10-22 01:32 PDT (History)
1 user (show)

See Also:

Attachments
Fix calculation of length in WebSocketChannel.cpp (1.10 KB, patch)
2009-10-21 18:45 PDT, Fumitoshi Ukai 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fumitoshi Ukai 2009-10-21 18:42:45 PDT 
length = length * 128 + *p & 0x7f;
is wrong, because & is less precedence than +.
Comment 1 Fumitoshi Ukai 2009-10-21 18:45:59 PDT 
Created attachment 41627 [details]
Fix calculation of length in WebSocketChannel.cpp
Comment 2 Alexey Proskuryakov 2009-10-21 23:57:04 PDT 
Comment on attachment 41627 [details]
Fix calculation of length in WebSocketChannel.cpp

r=me

Will this covered by layout tests once we have them?
Comment 3 Fumitoshi Ukai 2009-10-22 00:05:46 PDT 
(In reply to comment #2)
> (From update of attachment 41627 [details])
> r=me
> 
> Will this covered by layout tests once we have them?

Well, how about the following data sequence?
 0x81 0x81 0xCC 0x00 "unexpected data" 0xFF

It must skip 129 bytes after second 0x81, but wrong code gets 1 as length, so it would receive "unexpected data" unexpectedly.
Comment 4 WebKit Commit Bot 2009-10-22 00:11:31 PDT 
Comment on attachment 41627 [details]
Fix calculation of length in WebSocketChannel.cpp

Clearing flags on attachment: 41627

Committed r49932: <http://trac.webkit.org/changeset/49932>
Comment 5 WebKit Commit Bot 2009-10-22 00:11:35 PDT 
All reviewed patches have been landed.  Closing bug.
Comment 6 Fumitoshi Ukai 2009-10-22 01:32:12 PDT 
(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 41627 [details] [details])
> > r=me
> > 
> > Will this covered by layout tests once we have them?
> 
> Well, how about the following data sequence?
>  0x81 0x81 0xCC 0x00 "unexpected data" 0xFF

Oops. should be 0x80 0x81 0x81 0xCC 0x00 "unexpected data" 0xFF

> 
> It must skip 129 bytes after second 0x81, but wrong code gets 1 as length, so
> it would receive "unexpected data" unexpectedly.