Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/43254d526704c8246b1cd56a20d80597c42f9284 (Add an AccessibleNode constructor - first part of AOM Phase 3).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

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

+awhalley@ (Security TPM)

M63 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge  into the release branch ASAP. Thank you.

Looking at it.

OK, I have a fix.

https://chromium-review.googlesource.com/c/chromium/src/+/775616

The underlying bug is in Accessibility Object Model code, which is behind an experimental flag and not shipping anytime soon (but it's enabled in layout tests). As a result, I'm removing the release blocker and security labels.

Removing this from the security queue as per c#8.

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

commit d65c5acae44bfc63a40c3f7f4a2f7bdf111a6481
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Tue Nov 21 20:59:25 2017

AccessibleNode shouldn't cache an Element's Document.

AccessibleNode needs an owner document. If it's constructed without an
element, we get the document from the JavaScript context. That part is
fine. But if we construct it from an Element, we were caching its
Document - but elements can be reparented to a different document,
leading to a crash if the Element is reparented and then its original
document is deleted.

The solution is to not cache the Document if the AccessibleNode is associated
with an Element. Just get it from the Element.

Bug:  785802 
Change-Id: I8d67f9117a5d9a9c9efbd978ac4d1965e4c0eb2a
Reviewed-on: https://chromium-review.googlesource.com/775616
Reviewed-by: Alice Boxhall <aboxhall@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518387}
[modify] https://crrev.com/d65c5acae44bfc63a40c3f7f4a2f7bdf111a6481/third_party/WebKit/Source/core/dom/AccessibleNode.cpp
[modify] https://crrev.com/d65c5acae44bfc63a40c3f7f4a2f7bdf111a6481/third_party/WebKit/Source/core/dom/AccessibleNode.h

ClusterFuzz has detected this issue as fixed in range 518240:518474.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_asan_content_shell_drt
Platform Id: linux

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x61100004dc20
Crash State:
  blink::AXLayoutObject::GetDocument
  blink::AXObjectCacheImpl::PostPlatformNotification
  blink::AXObjectCacheImpl::NotificationPostTimerFired
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_content_shell_drt&range=500531:500604
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_content_shell_drt&range=518240:518474

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

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 5740463587065856 is verified as fixed, so closing issue as verified.

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