[Webkit-unassigned] [Bug 30827] Off-by-one hard-to-trigger memory corruption in CSSParser

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Darin Adler <darin at apple.com>  2009-10-27 11:06:36 PDT ---
The fact that allocating one more byte make the bug goes away makes me think
this is a buffer overrun of some sort.

The flex documentation mentions that you need to supply a buffer where the last
two bytes are 0 when explaining how to use the yy_scan_buffer, which I think is
analogous to how we use flex. So it makes sense that CSSParser sets the last
two characters to 0, and that should guarantee we never run off the end of the
buffer.

What I can't tell is exactly how flex guarantees it won't read or write more
than two characters past the end of the buffer. That guarantee somehow comes
from the state table that flex generates.

Trying to guess how the incorrect CSS in the lapack example affects this I
think it's possible the problem might stem from calling flex again after flex
returns an end of file indication.

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