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

If this is incorrect, please apply the Test-Predator-Wrong-Components 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

I'm not believing the regression range. I suppose I'll have to look into this.

Reproduces on linux, which is nice.

I'm not sure if this is a security issue for the real world or just an artifact of our test infrastructure.

We are deleting the scrolling container inside script run by an accessibilityController.addNotificationListener callback, while in the middle of processing the scroll. That's obviously bad, and maybe we can unwind the scroll processing stack when the object is disposed of, but that's ugly.

So, for the Accesibility folks who understand this stuff: Is if possible for the real-world code that executes via the following method to ever run script or otherwise delete elements:

void AXObjectCacheImpl::PostPlatformNotification(AXObject* obj,
                                                 AXNotification notification) {
  if (!obj || !obj->GetDocument() || !obj->DocumentFrameView() ||
      !obj->DocumentFrameView()->GetFrame().GetPage())
    return;
  // Send via WebFrameClient
  WebLocalFrameImpl* webframe = WebLocalFrameImpl::FromFrame(
      obj->GetDocument()->AXObjectCacheOwner().GetFrame());
  if (webframe && webframe->Client()) {
    webframe->Client()->PostAccessibilityEvent(
        WebAXObject(obj), static_cast<WebAXEvent>(notification));
  }
}

FWIW, it doesn't look like we can ever have this problem outside our test infrastructure. That makes me think this is WontFix.

We need to fix accessibility code so that we don't hit this stack and prevent other real bugs. Also, Dominic can confirm that this might be a real bug when accessibility is enabled.

Looking at the documentation we have for Accessibility APIs, as far as I can tell the API responds asynchronously, so the renderer has already completed its lifecycle before any changes come back in.

Our test infrastructure, on the other hand, executes arbutrary script synchronously. We could fix that to behave more like the real world by making the script execution asynchronous, but I suspect that's a lot of work to modify tests.

schenney: if this is a test-only issue, then we can mark this as a non-security bug, however it still seems bad that the fuzzer is invoking the code in question in a way that is triggering a crash. Can we change the fuzzer and/or the code to avoid that? 

flackr@ was fixing this, I believe, probabably due to another bug that landed on his plate.

Maybe see what happens when that lands?

dmazzoni: 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

Assigning to flakr@ based on c#13.

ClusterFuzz has detected this issue as fixed in range 537039:537060.

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

Fuzzer: inferno_twister
Job Type: windows_asan_content_shell
Platform Id: windows

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x114f81e81e58
Crash State:
  blink::PaintLayerScrollableArea::GetLayoutBox
  blink::PaintLayerScrollableArea::UpdateScrollOffset
  blink::ScrollableArea::ScrollOffsetChanged
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=531299:531319
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=537039:537060

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

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.

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