[Webkit-unassigned] [Bug 41601] New: Security: WebKit: Editing: multiple different NULL ptr crashes from the same repro

[bugzilla-daemon at webkit.org]

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

           Summary: Security: WebKit: Editing: multiple different NULL ptr
                    crashes from the same repro
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
               URL: http://code.google.com/p/chromium/issues/detail?id=483
                    28
        OS/Version: Windows Vista
            Status: NEW
          Severity: Normal
          Priority: P1
         Component: HTML Editing
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: skylined at chromium.org
                CC: eric at webkit.org


It appears that repros found using a fuzzer can trigger various crashes, my FuzzFramework found these two:
- WebCore::Node::hasTagName ReadAV at NULL (43ed3b87b6b20d63d6ffb8101c4a723f)
- WebCore::CompositeEditCommand::insertNodeAfter ReadAV at NULL (13e3a47574b811a7fa0c431eb5becc53)
The FuzzFramework also reported that the NULL pointer crash happened only 4 out of the 12 times it tried with the exact same repro file, which indicates the crash is not deterministic and thus may be a reentrancy/security issue.
When I manually try to reproduce I get only this one:
- WebCore::canHaveChildrenForEditing ReadAV at NULL (8a73a14a041b70b60a58e6bba9e1a7de)

Because a non-security NULL ptr would consistently crash with the same stack trace, I am worried that this is potentially more than a plain NULL ptr. Also, when I try to turn the repro files produced by FuzzFramework into one .html that reproduces the issue, it fails to trigger it and I can't figure out why.

The repro follows a pattern I have seen before ( issue 29341  and various others). We have had a lot of this type of NULL ptr crashes before, but never anything exploitable AFAIK, so this may not be a vulnerability either.

You can reproduce this issue by putting the following files in one folder, then run the Python script repro_server.py with one of the .repro.pickle.zip files as an argument. It will act as a small web server that serves the repro at http://localhost:28876 Point Chrome there and it will run the repro and crash.
http://chromium.googlecode.com/issues/attachment?aid=1972620968279643699&name=repro_server.py&token=6f05ae61b589413f8d876b6cf1fef038
http://chromium.googlecode.com/issues/attachment?aid=-5020044298225048251&name=WebCore..CompositeEditCommand..insertNodeAfter+ReadAV%40NULL+%2813e3a47574b811a7fa0c431eb5becc53%29.repro.pickle.zip&token=e0f25bb2f3dadb206ceb98b29dc51ffe
http://chromium.googlecode.com/issues/attachment?aid=4437006288659367084&name=WebCore..Node..hasTagName+ReadAV%40NULL+%2843ed3b87b6b20d63d6ffb8101c4a723f%29.repro.pickle.zip&token=39c35e61fecd479cf858e2247ecfea67

Also, you can unzip the .repro.pickle.zip files to get Python pickles that contain the repro steps; each of which is a http response served by repro_server.py in order. You can open them in a text editor to get an idea of what is being served.

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