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

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

Regression range here looks dubious. One layout test and one clang roll.

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

dmazzoni@ Looking into the stacktrace and blame info in code search suggests you might be able to help look into this case. It appears that clusterfuzz is hitting a case where |render_accessibility_| is uninitialized in [1]. This seems strange as the constructor explicitly initializes it to |nullptr| in [2]. Any ideas?

[1] https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?q=RenderFrameImpl::HandleWebAccessibilityEvent&sq=package:chromium&l=5930
[2] https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?gsn=render_accessibility_&l=1320

Clusterfuzz notes:

Uninitialized value was created by a heap deallocation content::RenderFrameImpl::FrameDetached

The POC creates a frame, creates a SVG document, then instructs the SVG document to adopt the frame.

OnSetAccessibilityMode includes the following suspicious remark:

    // Note: this isn't called automatically by the destructor because
    // there'd be no point in calling it in frame teardown, only if there's
    // an accessibility mode change but the frame is persisting.
    render_accessibility_->DisableAccessibility();
    delete render_accessibility_;
    render_accessibility_ = nullptr;

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

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

Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 

I can reproduce this crash, but I'm suspicious that it'd be possible to reproduce in the wild, so I don't think it's a release blocker.

In particular, the test seems to depend on accessibilityController.addNotificationListener, which is a test API. Normally there'd be no way to register a JavaScript callback that gets called for an internal accessibility event, and in particular the document lifecycle might not be in layout clean. Normally in production code, accessibility code is only called when layout is clean.

It's quite possible there is an underlying bug with adoptNode, I'm looking into it now.

Removing RBS for now. 

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

@dcheng, I spent a couple of hours debugging this but I'm a little stuck. Could you take a look?

What I can see is that a RenderFrameImpl is being destroyed, but subsequently we're still able to access that RenderFrameImpl via:

Document -> GetFrame -> WebLocalFrameImpl::FromFrame -> Client

With some logging I can confirm that the Document, Frame, and WebLocalFrameImpl are all still valid, i.e. they haven't been destroyed yet - but the Client is the RFI that's been deleted already.

Is there something wrong in AXObjectCacheImpl::PostPlatformNotification, or is the bug elsewhere?

Note that this is an SVG document - that's probably relevant.

dcheng: Uh oh! This issue still open and hasn't been updated in the last 29 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

M67 Stable promotion is coming 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.

*** Bulk Edit ***
M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

ClusterFuzz has detected this issue as fixed in range 558997:559001.

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

Fuzzer: inferno_twister
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  content::RenderFrameImpl::PostAccessibilityEvent
  blink::AXObjectCacheImpl::PostPlatformNotification
  blink::AXObjectCacheImpl::NotificationPostTimerFired
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

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

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

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

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

Bulk edit: reopening CF issues likely closed incorrectly due to https://chromium.googlesource.com/chromium/src/+/cd3ebc4c69d7c01770f37f34aad623aa4ab2b128

ClusterFuzz has detected this issue as fixed in range 558660:558661.

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

Fuzzer: inferno_twister
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  content::RenderFrameImpl::PostAccessibilityEvent
  blink::AXObjectCacheImpl::PostPlatformNotification
  blink::AXObjectCacheImpl::NotificationPostTimerFired
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

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

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

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