foolip -> is this related to  issue 632848 ?

No, my CL only added CHECKs, this is a use-after-free. Of the other things in the regression range, "Remove unnecessary checks in PaintLayer::backgroundIsKnownToBeOpaqueInRect" seems the least unrelated, as the crash is in FloatingObject::shouldPaintForCompositedLayoutPart which is at least somehow related to painting.

schenney@, can you take a look?

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

FYI clusterfuzz regression range may be inaccurate (bug 540799).

The regression range is definitely wrong. The change I made does not create or delete and objects at all. Still, I'll look at it.

Debug ASAN crashes with this assert.

ASSERTION FAILED: !currContainer->hasTransformRelatedProperty()
../../third_party/WebKit/Source/core/layout/LayoutObject.cpp(2123) : blink::LayoutSize blink::LayoutObject::offsetFromAncestorContainer(const blink::LayoutObject *) const
1   0x7f4cd469b718 WTFReportBacktrace(int)
2   0x7f4cc3c4413a blink::LayoutObject::offsetFromAncestorContainer(blink::LayoutObject const*) const
3   0x7f4cc3a9f254 blink::LayoutBoxModelObject::pushMappingToContainer(blink::LayoutBoxModelObject const*, blink::LayoutGeometryMap&) const
4   0x7f4cc3b47800 blink::LayoutGeometryMap::pushMappingsToAncestor(blink::LayoutObject const*, blink::LayoutBoxModelObject const*)
5   0x7f4cc3b48048 blink::LayoutGeometryMap::pushMappingsToAncestor(blink::PaintLayer const*, blink::PaintLayer const*)
6   0x7f4cc3e6a32a
7   0x7f4cc3e6bbac
8   0x7f4cc3e6bbac
9   0x7f4cc3e6bbac
10  0x7f4cc3e6bbac
11  0x7f4cc3e6bbac
12  0x7f4cc3e6bbac
13  0x7f4cc3e6bbac
14  0x7f4cc3e699f7
15  0x7f4cc3e86b8e blink::PaintLayerCompositor::updateIfNeeded()
16  0x7f4cc3e85f4d blink::PaintLayerCompositor::updateIfNeededRecursiveInternal()
17  0x7f4cc3e85764 blink::PaintLayerCompositor::updateIfNeededRecursive()
18  0x7f4cc2b3eae0 blink::FrameView::updateLifecyclePhasesInternal(blink::DocumentLifecycle::LifecycleState)
19  0x7f4cc2b3db02 blink::FrameView::updateAllLifecyclePhases()
20  0x7f4cc429b949 blink::PageAnimator::updateAllLifecyclePhases(blink::LocalFrame&)
21  0x7f4cd4053de5
22  0x7f4cd431b1c8 blink::WebViewImpl::updateAllLifecyclePhases()
23  0x7f4cf181dd4a content::RenderWidget::UpdateVisualState()
24  0x7f4cf12f4f3a content::RenderWidgetCompositor::UpdateLayerTreeHost()
25  0x7f4ce7b6babd cc::LayerTreeHost::RequestMainFrameUpdate()
26  0x7f4ce7e0ce10 cc::ProxyMain::BeginMainFrame(std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> >)

chrishtr added the assert that's hitting in Debug. This is not a minimized fuzz case, which is annoying.

The crash is in code added by this, relanded Aug 23:

https://chromium.googlesource.com/chromium/src/+/77f8e3dd7c2c7feb739b9918a2ecca94e7ad3e36

Somehow we are deleting the layout object used by a FloatingObject without deleting the FloatingObject, and then calling FloatingObject::shouldPaintForCompositedLayoutPart and accessing bad layout object memory.

To debug this you need to remove a couple of asserts that hit first, though they are not immediately related, it seems.

wkorman, chrishtr: Let me know if you want me to keep working on this. You added the code but it's not clear to me that the underlying bug is your fault - you've just started tickling it.

I have not looked at detail here yet but http://crrev.com/2283413003 for  http://crbug.com/624028  could be related, as one fix for floats re: use-after-free. I am not sure that patch made it into M54. In fact it looks like it was recently reverted.

+flackr@ who has shared in the floating object explorations per c12.

So this is indeed probably due to reversion of the patch landed for 624028, so duping that one into this, as this is the more serious bug and we want the security tracking on it.

wfh@, could you please provide access to https://bugs.chromium.org/p/chromium/issues/detail?id=644605 for the people CC'ed on this bug and the owner, robhogan@.

It appears we have a security issue with the patch, and one without the patch.

@flackr: Sorry, it was Mr. Hogan, I think I got my Robs swapped in hastiness. You can still follow along for fun if not profit.

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

commit 3453e2368a018544e7143e60afbc7a1454e848ed
Author: robhogan <robhogan@gmail.com>
Date: Wed Oct 12 21:29:52 2016

Copy float list of ruby base when merging it with a sibling

When merging two ruby bases ensure that the new base has a complete float list.

A 2nd go at https://crrev.com/6f208d569f6bd2488f2f2f6f9004e54417f78782

BUG= 619380 ,  624028 , 644605,  644803 

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

[modify] https://crrev.com/3453e2368a018544e7143e60afbc7a1454e848ed/third_party/WebKit/LayoutTests/fast/block/float/float-reparent-during-detach-crash.html
[modify] https://crrev.com/3453e2368a018544e7143e60afbc7a1454e848ed/third_party/WebKit/Source/core/layout/FloatingObjects.cpp
[modify] https://crrev.com/3453e2368a018544e7143e60afbc7a1454e848ed/third_party/WebKit/Source/core/layout/FloatingObjects.h
[modify] https://crrev.com/3453e2368a018544e7143e60afbc7a1454e848ed/third_party/WebKit/Source/core/layout/LayoutRubyBase.cpp

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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