[Webkit-unassigned] [Bug 49652] New: listing+style(display:block+:first-letter)+selection = memory under allocation

Wed Nov 17 01:44:39 PST 2010

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

           Summary: listing+style(display:block+:first-letter)+selection =
                    memory under allocation
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
               URL: http://code.google.com/p/chromium/issues/detail?id=634
                    54
        OS/Version: Windows Vista
            Status: NEW
          Severity: Normal
          Priority: P1
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: skylined at chromium.org
                CC: eric at webkit.org

Created an attachment (id=74092)
 --> (https://bugs.webkit.org/attachment.cgi?id=74092&action=review)
Repro3 (WTF::Vector::reserveCapacity)

This affects all versions of Chrome and  Safari+Nightly but not Safari stable.

Repro3.html:
<html><head><script>
  function go() {
    document.designMode= "on";
    document.write('<listing><style>*{display/*X*/:block}:first-letter{width:0}</style>');
    window.find('X');
  }
</script></head><body onload="go();"></body></html>

The above will trigger a debug breakpoint (or ASSERT in Safari+Nightly) when the code tries to allocate a negative number of bytes (~0xFFFFFFFA).

By adding additional characters before the "X" in the style tag, one can decrease the number of bytes it tries to allocate further, I have not found a way to increase it. It appears as if the start of the selection is determined to be relative to the "X" in the style tag, but the end is incorrectly determined to be relative to the start of the "display" keyword.

Also, if you remove the "FindString" line, the repro will not crash immediately. At that point you can see in the page that the <style> tag is both interpreted as text AND parsed as an actual style tag, which may be a hint to the root cause of this issue. Clicking anywhere in the page will cause the same crash as the original repro.

Repro2.html is a variation that does not cause an immediate crash, but will crash the browser when you click on the page. This crash has a different stack than repro3.html, but appears related because the crash is also caused by an ASSERT failing because the size of a memory allocation is negative (and in the same range as repro3.html).

I've not been able to pin down exactly what is going on nor find a way to exploit this; I am worried there is some way in which this apparent under allocation of memory can be abused to cause memory corruption and I'm marking as security for that reason.

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