Seems to be related to https://chromium-review.googlesource.com/565238

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

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

IMO, this looks more likely to be caused by the first CL in the regression range: https://chromium-review.googlesource.com/c/582673/

URGENT - PTAL.
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the M61 branch #3163 ASAP to have enough baking time in Beta before Stable promotion. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

Looks like the regression range is in M62, changing milestone.

I guess we access released LayoutObject in traversing old selection range.
We should skip kNone LayoutObject 

I want to test it on each platform but
https://commondatastorage.googleapis.com/chromium-browser-asan/index.html
 doesn't include latest builds.

ClusterFuzz has detected this issue as fixed in range 489602:489609.

Detailed report: https://clusterfuzz.com/testcase?key=5237925330812928

Fuzzer: bj_broddelwerk
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x6120001c4180
Crash State:
  blink::LayoutObject::ChildAt
  blink::CollectInvalidationSet
  blink::LayoutSelection::Commit
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=489260:489272
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=489602:489609

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5237925330812928


See https://github.com/google/clusterfuzz-tools for more information.

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

No, it is not fixed yet. I'm reverting the suspicious CL.

ClusterFuzz testcase 5237925330812928 is verified as fixed, so closing issue as verified.

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

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

commit 24bd4066e46f42bdafe467100538f4c6e940ff55
Author: yoichio <yoichio@chromium.org>
Date: Thu Jul 27 16:39:08 2017

Revert of Remove ClearSelection() from Layout{BlockFlow,Inline}::WillbeDestroyed() (patchset #1 id:1 of https://codereview.chromium.org/2811333003/ )

Reason for revert:
This causes use-after-free:
 crbug.com/748718 

Original issue's description:
> Remove ClearSelection() from Layout{BlockFlow,Inline}::WillbeDestroyed()
>
> LayoutView::ClearSelection was originally introduced at 2004 to assure no
>  crash:
> https://chromium.googlesource.com/chromium/src/+/10f7ac6ea6784e33161c7979e9a59c5e2cae14b5
>
> Even now that code doesn't make sense because we update LayoutSelection after
> layout in following sequence:
> 1. FrameView::PerformPostLayoutTasks() checks
>  LayoutSelection::SetHasPendingSelection()
> 2. PaintLayerCompositor::UpdateIfNeededRecursiveInternal() calls
>  LayoutSelection::Commit() and it updates layout selection.
>
>
>
> BUG= 708453 
>
> Review-Url: https://codereview.chromium.org/2811333003
> Cr-Commit-Position: refs/heads/master@{#464352}
> Committed: https://chromium.googlesource.com/chromium/src/+/230b4e0eb7f14d23c70bc4134b8a23a9ddccd5a8

TBR=yosin@chromium.org,eae@chromium.org,kojih@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 708453 ,  748718 

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

[modify] https://crrev.com/24bd4066e46f42bdafe467100538f4c6e940ff55/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp
[modify] https://crrev.com/24bd4066e46f42bdafe467100538f4c6e940ff55/third_party/WebKit/Source/core/layout/LayoutInline.cpp

My final DCHECK still failed:
https://chromium-review.googlesource.com/c/589049
Working on...

Reopening since the crash still exist in latest canary-62.0.3178.0, currently 2.85%, 225 reports with 200+ unique clients in Dev -62.0.3175.3 . Please have a fix ASAP.

Link to the builds which introduced the crash
=============================================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27blink%3A%3ALayoutObject%3A%3AChildAt%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-property-selector,samplereports:5,productversion:1000,+osversion

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

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

Since this was accidentally marked as fixed by clusterfuzz, merged to another 
issue.

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

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