credit: miaubiz http://code.google.com/p/chromium/issues/detail?id=88216 VULNERABILITY DETAILS counter related use after free without memory debugging tools it just hangs forever, asan and vg say it's use after free. VERSION Chrome Version: daily + canary + trunk Operating System: linux 64bit, win7 bisect-builds puts it here: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=88127:88339 probably the webkit roll to 88326 REPRODUCTION CASE attached FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: renderer/hang Crash State: Invalid read of size 8 at 0x1D289C8: WebCore::CounterNode::insertAfter(WebCore::CounterNode*, WebCore::CounterNode*, WTF::AtomicString const&) (CounterNode.cpp:202) Address 0xf4c45a0 is 16 bytes inside a block of size 72 free'd TESTCASE <style> div::after { content:counter(ctr); counter-increment:ctr; } </style> <div></div> <div> <div></div> </div> <style> div { counter-reset:ctr; } </style> Checking out the webkit range from the regression, looks like it might be coming from http://trac.webkit.org/changeset/88308 (which makes changes to content property and the repro has it too :). I cannot see anything else counter node specific in the range. Counter Node are the trouble of past, present and future for security because of CounterDirectiveMap and cloning it might be causing this. Simon, can you please take a look.
<rdar://problem/9745926>
Created attachment 102305 [details] Minimized repro
I will try to describe the issue here although this is rather complex. Essentially the way CounterNode trees are created relies on makeCounterNode() being called in the order that the render objects fall in the render tree. When we have a dom such as <table> <td> <a> </td> <b> </table> The nodes are created in the order a then b. However, because b is not within a table section it will be moved out of the table resulting an an actual hierarchy of <b> <table> <td> <a> </td> </table> When counters exist on both a and b the counter node for a is created first and then will later have to become a child of b. The code does not handle this and with a slightly more complicated tree you end up with situations where nodes with different parents are linked as siblings. This code is incredibly fragile to dom mutation and in many cases this ends up causing CounterNodes to be destroyed without being unlinked from the tree. The correct fix for this bug is to either make the existing code handle complex mutations or to reimplement css counters. I believe they are currently very slow so I would tend to lean towards the second alternative. In the meantime there is a relatively simple way to ensure that other situations like this do not result in the use of stale pointers. Within the destructor for CounterNode we can check whether the node is still linked into the tree and if so unlink it. In the general case (anything that doesn't currently result in a stale pointer) this will involve 5 null checks in the destructor. In cases where stale pointers are currently caused a somewhat complex safe unlinking must occur. This fix will turn this and other similar bugs into purely functional bugs with no security impact.
This no longer has security implications after http://trac.webkit.org/changeset/92630 However it is still a functional bug. Assuming this is still open once the above revision rolls into relevant projects the product can be changed from "Security" to "WebKit".
Dropping Security per above comment.
Could you please re-title the bug to describe what it tracks now?
I think Elliot is working on the Counter Node rewrite. so this bug does not need individual tracking.