[Webkit-unassigned] [Bug 185475] REGRESSION (r231479): com.apple.WebCore crash in WebCore::DocumentLoader::stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 9 11:18:38 PDT 2018


Daniel Bates <dbates at webkit.org> changed:

           What    |Removed                     |Added
           Keywords|                            |Regression

--- Comment #5 from Daniel Bates <dbates at webkit.org> ---
This regression is specific to WebKit2 and the new code path that we now use to check X-Frame-Options in NetworkProcess following r231479 (*).

The issue is that DocumentLoader::stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() may cause its own destruction as a result of dispatching a DOM load event at the <iframe> because JavaScript can do anything in the onload handler including removing the <iframe>. And when a frame is removed we stop its document loader and destroy it among other cleanup operations (**). Prior to r231479 DocumentLoader::stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() was a private function and only called by DocumentLoader::responseReceived(). And DocumentLoader::responseReceived() takes out a ref on itself almost from the start and hence prevents itself from being destroyed should it need to invoke stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() and stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() causes the associated frame to be removed. Following r231479 stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() is now public and can also be invoked by WebResourceLoader. But WebResourceLoader does not take out a ref for DocumentLoader before invoking stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied(). So, stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() can cause the document loader to destroy itself before reaching the end of the function by (**). One way to fix this issue is to have stopLoadingAfterXFrameOptionsOrContentSecurityPolicyDenied() take out a ref on itself from the getgo.

(*) We only use this new code path if both the experimental feature "Restricted HTTP Response Access" (RuntimeEnabledFeatures::sharedFeatures().restrictedHTTPResponseAccess()) and Setting::networkProcessCSPFrameAncestorsCheckingEnabled() are enabled. These two settings are enabled when running tests in WebKitTestRunner.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180509/b231c7e8/attachment.html>

More information about the webkit-unassigned mailing list