Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/fe8c4db4003022f5cb12506a15cc78ea6633bbdf ([RootLayerScrolls] Flip RuntimeEnabledFeatures flag to experimental).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

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

@pnoland, do you think this is a dupe of issue 806631?

Potentially, since that only got merged to M65 a few hours ago. I'll re-run the "fixed" task.

This doesn't look like a duplicate to me.  This bug is happening during document tear-down.

I'm going to speculatively add a null-check after this line:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/scrolling/TopDocumentRootScrollerController.cpp?rcl=1fb4857ddb46a7e5babc1a64830cdd97ce7d1d12&l=217

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

commit 7d635e268594cc7db9f4e214ec16ffc7385647bc
Author: Stefan Zager <szager@chromium.org>
Date: Sat Feb 03 01:12:45 2018

Speculative fix for crash in document tear-down.

BUG= 808341 
R=skobes@chromium.org

Change-Id: I298ffd2134ec5021682bc443a5c6a9ba4a9cc13c
Reviewed-on: https://chromium-review.googlesource.com/899928
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534226}
[modify] https://crrev.com/7d635e268594cc7db9f4e214ec16ffc7385647bc/third_party/WebKit/Source/core/page/scrolling/TopDocumentRootScrollerController.cpp

I can't reproduce this using the clusterfuzz reproduce tool.

ClusterFuzz has detected this issue as fixed in range 535692:535694.

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

Fuzzer: mbarbella_js_mutation_layout
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  blink::LayoutObject::MaybeClearIsScrollAnchorObject
  blink::RootFrameViewport::SetLayoutViewport
  blink::PaintLayerScrollableArea::Dispose
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=533693:533696
Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=535692:535694

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

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.

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

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

Interesting, looks like a clang roll fixed this? Seems strange...should I poke at this more or do we take clusterfuzz's word for it?

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