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

ymalik@, could you please take a look? Seems that you CL is the culprit:

The result is a list of CLs that change the crashed files. 

Author: ymalik
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/121a3d55a69bb82a46ee9e3159a0be1810052368
Time: Wed Oct 12 15:49:55 2016
Lines 314 of file ScrollAnchor.cpp which potentially caused crash are changed in this cl (frame #1, "blink::ScrollAnchor::clear"). 

File LayoutObject.cpp is changed in this cl (and is part of stack frame #4, "blink::LayoutObject::destroy")
Minimum distance from crash line to modified line: 0. (file: ScrollAnchor.cpp, crashed on: 312, modified: 312).

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

commit 889397888480b49f01ed18a04ce9eb05f30ca2b5
Author: ymalik <ymalik@chromium.org>
Date: Wed Oct 19 22:45:10 2016

Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear
the scroll anchor for #main (and not #nested because layoutObject->parent() is null
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will be
called on #nested's PLSA and we will be working with a stale anchor.

BUG= 656314 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://chromiumcodereview.appspot.com/2433873003
Cr-Commit-Position: refs/heads/master@{#426314}

[modify] https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5/third_party/WebKit/Source/core/layout/ScrollAnchor.cpp
[modify] https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5/third_party/WebKit/Source/core/layout/ScrollAnchor.h
[modify] https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5/third_party/WebKit/Source/core/layout/ScrollAnchorTest.cpp
[modify] https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp

ClusterFuzz has detected this issue as fixed in range 426296:426375.

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

Fuzzer: bj_broddelwerk
Job Type: linux_asan_content_shell_drt
Platform Id: linux

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x611000293168
Crash State:
  blink::ScrollAnchor::clear
  blink::PaintLayer::~PaintLayer
  blink::PaintLayer::~PaintLayer
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_content_shell_drt&range=424153:424757
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_content_shell_drt&range=426296:426375

Minimized Testcase (3.92 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95Iyom8udAUXdTbW9WEUl4K33w8gpb1PJYdLwslf4Lrh3uWv1DaBoh_UYq_SGzlISo2VDcWMVYbqAWcPM9sdbVuXUMcPOpjA-srGHVv9zT-nPNsvzXsXd93amRvorIwk4hyYP7eU6N8cjMGLE6TNGKakXlcng?testcase_id=4587408899440640

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.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

Removing M55 labels, as per Comment 5 this was introduced in M56.

mbarbella@, mind taking a look at what confused sheriffbot?

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