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

tkent@, could you please take a look? Could this have been caused by https://chromium.googlesource.com/chromium/src//+/5bfffca95444ba872b0a7faeaf956e92ab18639f?

It seems HTMLMeterElement::canContainRangeEndPoint() triggers this issue.

Cleaner repro:

<style></style>
<div id="d" contenteditable=""></div>
<script>
var test0 = document.getElementById("d")
test0.focus();
test0.appendChild(document.createElement("meter"))
setTimeout(function() {
  document.styleSheets[0].insertRule('#d {content: counter(c, katakana);}');
  test0.textContent = "PASS";
})
</script>

In CaretBase::caretLayoutObject(Node* node).
 - |node| is being detached from the document tree, and it has an obsolete LayoutObject.
 - caretRendersInsideNode(node) in this function calls HTMLMeterElement::canContainRangeEndPoint(), and it updates the layout tree.  It means LayoutObject for the METER is deleted.
 - Local variable |layoutObject| becomes a stale pointer.

I think we may remove updateLayoutTreeForForNode() in HTMLMeterElement::canContainRangeEndPoint().

yosin@ takes this over.

We should keep LayoutObject in CaretBase to avoid calling caretLayoutObject() with updating layout object at recalc style, and layout change.

yoichio: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

yoichio@, do you have any updates on this? Thanks!

This is Heap-use-after-free security bug. 
Sanity of the script and usage in wild is important index to prioritize?
Other such bugs from clusterfuzz have been fixed quickly.
https://bugs.chromium.org/p/chromium/issues/list?can=1&q=Heap-use-after-free+clusterfuzz&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids

WDYK, yosin@?

We're doing a security fix-it right now; would it be possible to get this fixed this week?

I'm working on this issue.

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

commit e4edfb63d1b068c5ab5dc6b91edf75c108ebc433
Author: yoichio <yoichio@chromium.org>
Date: Wed May 25 07:23:06 2016

Check node->layoutObject in CaretBase::caretLayoutObject

In CaretBase::caretLayoutObject(Node* node),
if caretRendersInsideNode(node) calls HTMLMeterElement::canContainRangeEndPoint,
 it updates the layout tree.  It means LayoutObject for the METER can be deleted.
This is bad design. We should make caret painting algorithm clean.

BUG= 608817 

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

[modify] https://crrev.com/e4edfb63d1b068c5ab5dc6b91edf75c108ebc433/third_party/WebKit/Source/core/editing/CaretBase.cpp

Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Request-XX label, where XX is the Chrome milestone.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz

Thanks yoichio!

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Please merge your change to M52 branch 2743 before 3:00 PM PST tomorrow, Tuesday (06/07) so we can take it for this week beta release. Thank you.

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

commit 59c23e7f2a1eeeafa8040eb50a193f2e3a29a02f
Author: Yoichi Osato <yoichio@chromium.org>
Date: Tue Jun 07 02:17:39 2016

Check node->layoutObject in CaretBase::caretLayoutObject

In CaretBase::caretLayoutObject(Node* node),
if caretRendersInsideNode(node) calls HTMLMeterElement::canContainRangeEndPoint,
 it updates the layout tree.  It means LayoutObject for the METER can be deleted.
This is bad design. We should make caret painting algorithm clean.

BUG= 608817 

Review-Url: https://codereview.chromium.org/1972523002
Cr-Commit-Position: refs/heads/master@{#395822}
(cherry picked from commit e4edfb63d1b068c5ab5dc6b91edf75c108ebc433)

Review URL: https://codereview.chromium.org/2042153002 .

Cr-Commit-Position: refs/branch-heads/2743@{#256}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/59c23e7f2a1eeeafa8040eb50a193f2e3a29a02f/third_party/WebKit/Source/core/editing/CaretBase.cpp

ClusterFuzz has detected this issue as fixed in range 395786:395828.

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

Fuzzer: attekett_dom_fuzzer
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x611000045de0
Crash State:
  blink::LayoutObject::containingBlock
  blink::CaretBase::invalidateLocalCaretRect
  blink::FrameSelection::nodeWillBeRemoved
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=390316:390338
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=395786:395828

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv94_DGoNp8fVMd_haDgN_JwnuqFwPLdptMj-On8JzzwoIHQhKKVVFFsq6to-ulZIM7beD3c_0wvmRbz-hVqURKSZ50yS6oAZg93uvhqRgAmse4ai5ZeCsD649OKJMOm6rB0U0Il7wMvrz4uPYUkXUGGo2ZR3U1OZScEvabEhiy0dOjGGuFg


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.

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

commit 59c23e7f2a1eeeafa8040eb50a193f2e3a29a02f
Author: Yoichi Osato <yoichio@chromium.org>
Date: Tue Jun 07 02:17:39 2016

Check node->layoutObject in CaretBase::caretLayoutObject

In CaretBase::caretLayoutObject(Node* node),
if caretRendersInsideNode(node) calls HTMLMeterElement::canContainRangeEndPoint,
 it updates the layout tree.  It means LayoutObject for the METER can be deleted.
This is bad design. We should make caret painting algorithm clean.

BUG= 608817 

Review-Url: https://codereview.chromium.org/1972523002
Cr-Commit-Position: refs/heads/master@{#395822}
(cherry picked from commit e4edfb63d1b068c5ab5dc6b91edf75c108ebc433)

Review URL: https://codereview.chromium.org/2042153002 .

Cr-Commit-Position: refs/branch-heads/2743@{#256}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/59c23e7f2a1eeeafa8040eb50a193f2e3a29a02f/third_party/WebKit/Source/core/editing/CaretBase.cpp

Groovy - $3,500 for this one!

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

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

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