Bug 30656

Summary:

Fix calculation of length in WebSocketChannel.cpp

Product:

WebKit

Reporter:

Fumitoshi Ukai <ukai>

Component:

WebKit Misc.

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

commit-queue

Priority:

Version:

528+ (Nightly build)

Hardware:

OS:

All

Attachments:

Description	Flags
Fix calculation of length in WebSocketChannel.cpp	none

Fumitoshi Ukai

Reported 2009-10-21 18:42:45 PDT

length = length * 128 + *p & 0x7f; is wrong, because & is less precedence than +.

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 attachment proposed patch, testcase, etc.

Fumitoshi Ukai

Comment 1 2009-10-21 18:45:59 PDT

Created attachment 41627 [details] Fix calculation of length in WebSocketChannel.cpp

Alexey Proskuryakov

Comment 2 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?

Fumitoshi Ukai

Comment 3 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.

WebKit Commit Bot

Comment 4 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>

WebKit Commit Bot

Comment 5 2009-10-22 00:11:35 PDT

All reviewed patches have been landed. Closing bug.

Fumitoshi Ukai

Comment 6 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.

Note You need to log in before you can comment on or make changes to this bug.