Changelog: https://chromium.googlesource.com/chromium/src/+log/34b990b50b984c81eb660e8ceaf9c2d431c7aad6..86fa8831dcb7154bd60f77a532953517797d4f10?pretty=fuller

From the above change log suspecting the below change
Review-Url: https://codereview.chromium.org/2169453002

Jochen@: Could you please check if this is caused with respect to your change, if not please help us in reassign the issue to the right owner. 

Thanks!

And this would be an uxss bug I guess

ClusterFuzz has detected this issue as fixed in range 407760:407770.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5179748171120640

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_ubsan_vptr_chrome
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !contentFrame() in HTMLFrameElementBase.cpp
  blink::HTMLFrameElementBase::didNotifySubtreeInsertionsToDocument
  blink::ContainerNode::notifyNodeInserted
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_ubsan_vptr_chrome&range=407429:407440
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_ubsan_vptr_chrome&range=407760:407770

Minimized Testcase (0.82 Kb): https://cluster-fuzz.appspot.com/download/AMIfv97_95eC9l0lq9Lp0ZRBakb5tCOPuY4DyCa6kD8j-JWdwoPWEwbRSGMpot92x31Xtt8fLlt8kjvmavceUHlRvrXCk0n_csHdnuK7U9fbnJwAPGuqddZZ_QYpCxATzLqy0sFTonRIx_35FtwQCDmkbpEI10Lzpw?testcase_id=5179748171120640

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

What happens is that the appendChild in 24 of the minimized repro inserts a frame with a javascript url

that javascript url is executed which in turn inserts the frame at a different location of the tree, triggering the security check

Dominic, I guess this would also be addressed by your proposal to make javascript url execution asynchronous?

Yes, making the load asynchronous would cut off that route.

This is the CF case I was looking at on Friday; we should try to fix the crash and land jochen's patch, which asserts that we never try to re-insert an already attached frame owner element.

Let's reland the SECURITY_CHECK that there's no content frame when we insert a HTMLFrameOwnerElement, since that means we previously forgot to detach something.

DOM team should investigate why this assert is failing.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/baf4f1f0cca9c704ff01de23e9360a1deef00cb4

commit baf4f1f0cca9c704ff01de23e9360a1deef00cb4
Author: jochen <jochen@chromium.org>
Date: Mon Dec 05 15:21:05 2016

Assert that we never insert an frame element that already has a frame

BUG=628942, 631151 
R=dominicc@chromium.org

Review-Url: https://codereview.chromium.org/2190523002
Cr-Commit-Position: refs/heads/master@{#436294}

[modify] https://crrev.com/baf4f1f0cca9c704ff01de23e9360a1deef00cb4/third_party/WebKit/Source/core/html/HTMLFrameElementBase.cpp

Issue 705447 has been merged into this issue.

 Issue 705446  has been merged into this issue.

Issue 710721 has been merged into this issue.

 Issue 712780  has been merged into this issue.

tkent has a fix for this in https://chromium-review.googlesource.com/c/536673/.

 Issue 733416  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/772e2f76cdab92e73a50192f07b2ea7036c06b79

commit 772e2f76cdab92e73a50192f07b2ea7036c06b79
Author: Kent Tamura <tkent@chromium.org>
Date: Thu Jun 15 08:14:24 2017

Do not crash if we load an IFRAME twice.

This CL moves a SECURITY_CHECK() from
HTMLFrameElementBase::DidNotifySubtreeInsertionsToDocument() to InsertedInto(),
and allow having ContentFrame() in DidNotifySubtreeInsertionsToDocument().

What happens in the test case:
1. body.appendChild(fragment)
2.  DOM tree is updated.
3.  InsertedInto() for script
4.  InsertedInto() for iframe1
5.  DidNotifySubtreeInsertionsToDocument() for script;
    This executes body.appendChild(iframe1)
6.   iframe1 is removed from the tree
7.   iframe1 is added to the tree
8.   InsertedInto() for iframe1
9.   DidNotifySubtreeInsertionsToDocument() for iframe1;
     ContentFrame() is created synchronously.
10. DidNotifySubtreeInsertionsToDocument() for iframe1
    ==> We hit SECURITY_CHECK() without this CL

Bug:  631151 
Change-Id: I55d8c8b8c0cf496a0022b9d85ba80dcda44099cd
Reviewed-on: https://chromium-review.googlesource.com/536673
Commit-Queue: Kent Tamura <tkent@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#479634}
[modify] https://crrev.com/772e2f76cdab92e73a50192f07b2ea7036c06b79/third_party/WebKit/LayoutTests/html/README.md
[add] https://crrev.com/772e2f76cdab92e73a50192f07b2ea7036c06b79/third_party/WebKit/LayoutTests/html/embedded_content/iframe-load-before-load-crash.html
[modify] https://crrev.com/772e2f76cdab92e73a50192f07b2ea7036c06b79/third_party/WebKit/Source/core/html/HTMLFrameElementBase.cpp

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.