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 don't see anything webaudio related in the regression range, except for some webrtc related CLs.

Can a WebAudio owner please take a look?

...(from main thread)...
OfflineAudioDestinationHandler::StartRendering()
-> CrossThreadBind(OfflineAudioDestinationHandler::StartOfflineRendering)

...(in audio thread)...
OfflineAudioDestinationHandler::StartOfflineRendering()
-> OfflineAudioDestinationHandler::DoOfflineRendering()

I believe the problem here is that |Handler| might have gone while DoOfflineRendering(). Not sure how to keep RefPtr<OfflineAudioDestinationHandler> alive, and how Member<OfflineAudioDestinationNode> can wait until the handler is destroyed.

Note: rtoy@ and I tried to reproduce locally with Linux, Windows and MacOSX, but we haven't encountered any crash with the repro case.

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

commit c60b3abb3e464270810f2cccb4b700bf011fbee8
Author: Hongchan Choi <hongchan@chromium.org>
Date: Mon Sep 25 20:59:44 2017

Add HasPendingActivity() in OfflineAudioContext

This is a speculative fix for the associated issue. It is to prevent
OfflineAudioContext from going away while there is an ongoing rendering
task.

- |run-webkit-tests| with "--enable-leak-detection" shows no leak.

Bug:  763798 
Change-Id: Id41e6966bed7d5af946ae29fdeea5a2a43af8220
Reviewed-on: https://chromium-review.googlesource.com/679287
Commit-Queue: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504162}
[modify] https://crrev.com/c60b3abb3e464270810f2cccb4b700bf011fbee8/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.h
[modify] https://crrev.com/c60b3abb3e464270810f2cccb4b700bf011fbee8/third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp
[modify] https://crrev.com/c60b3abb3e464270810f2cccb4b700bf011fbee8/third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.h

Marking as fixed and waiting for CF to confirm the fix.

CF indicated that the issue has not been fixed. Reopening.

haraken@ Could you take a look at the CF stack trace?

...
#0 0xeace136 in blink::OfflineAudioDestinationHandler::RenderIfNotSuspended third_party/WebKit/Source/modules/webaudio/OfflineAudioDestinationNode.cpp:362
...

The line 362 is literrally the end of the function, so we can't tell where this "use-after-poison" is happening.

IIUC, the "use-after-poison" means the destructor is called but the memory region is not yet deleted by Oilpan collector.

palmer@

Could you help me with reproducing this locally? I haven't had any luck on my windows, linux and osx machines. Also we haven't changed the affected code since 2015. (other than Blink Reformat)

#14: Did you use an ASan build to reproduce?

Sometimes fuzzers uncover issues that have existed for a long time.

#15: I used the test case and the build included in the CF issue above. Had no luck after running it about 4 hours. Also I built the ASAN with gn args in the issue, but couldn't get it reproduced.

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

Job Type: linux_asan_chrome_mp
Crash Type: 
Crash Address: 
Crash State:
  
Sanitizer: address (ASAN)

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

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

#17 indicates that CF was not able to reproduce the issue on Linux ASan, FWIW. Pinged hongchan on internal chat about other possibilities.

In #15, I was talking about Windows platform. Were you able to reproduce it locally?

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

ClusterFuzz has detected this issue as fixed in range 505679:505750.

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

Fuzzer: inferno_layout_test_fuzzer
Job Type: windows_asan_content_shell
Platform Id: windows

Crash Type: Use-after-poison READ 4
Crash Address: 0x5d14b138
Crash State:
  blink::OfflineAudioDestinationHandler::RenderIfNotSuspended
  blink::OfflineAudioDestinationHandler::DoOfflineRendering
  blink::RunCrossThreadClosure
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=491334:491349
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=505679:505750

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

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

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

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

+awhalley@ (Security TPM) for M63 merge review

I'm not sure what needs to be merged.  The speculative fix in c#9 didn't seem to actually fix the issue as far as we can tell, and the clusterfuzz fixed region doesn't actually include that fix.  The only WebAudio CL in that range has to do with AudioWorklets and is probably not related to any actual fix. I don't think we want to merge that CL into M63.

hongchan is OoO until Monday.

Yes, I don't think we need to do anything here. The issue itself might be extremely flaky so even CF couldn't reproduce consistently and gave up.

Removing "Merge-Review-63" label based on comments #28 and #29.

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