Call loops can be triggered with this code (100% CPU use): http://skypher.com/SkyLined/Repro/Safari/document.body%20DOMSubTreeModified%20event%20loop/100%25%20CPU.html <SCRIPT> document.addEventListener("DOMSubtreeModified", function () { event.srcElement.innerHTML='<BR>'; }, true); document.body.setAttribute('x',0) </SCRIPT> Recursive function calls can be triggered with this code (stack exhaustion): http://skypher.com/SkyLined/Repro/Safari/document.body%20DOMSubTreeModified%20event%20loop/Stackoverflow.html <SCRIPT> document.addEventListener("DOMSubtreeModified", function () { event.srcElement.innerHTML = '<TH><title></title>'; }, true); document.body.setAttribute('x',0) </SCRIPT>
<rdar://problem/6131021>
The second example I provided actually ends up overwriting EIP with NULL in WebKit nightly. Marking as security sensitive - control over EIP could lead to arbitrary code execution. I have no proof that this can be used to overwrite EIP with anything but NULL, but I can't prove that it's impossible.
I'm surprised we don't already have an arbitrary JS recursion limit for number of calls back into JS from C++. Maybe we do and I'm just not aware of it. That would be a simple way to fix this class of problems. Marking this as p1 since it's a reproducible crash.
Created attachment 28236 [details] stack overflow crash
Should this be a security bug? I thought there were many ways one could accomplish stack exhaustion or 100% cpu in JS?
No OOM crashes are not considered security. there should be numerous ways for 100% cpu usage.
Yes, I reported this way back when we (briefly) treated renderer DoS as a security issue. I've updated the flags, except importance as I have no idea what to set it to. You can probably just close this out, as we have more important things to focus on.
Mass move bugs into the DOM component.