This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

hongchan, can you please take a look? Thanks!

I believe I have a tentative fix for this:
https://codereview.chromium.org/2854463002

I will land this soon.

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

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

commit d94da1744907ed1bb90e37756806841609b0cc52
Author: hongchan <hongchan@chromium.org>
Date: Tue May 02 18:55:46 2017

Improve thread creation in plaform/audio/AudioDestination

After the introduction of the new rendering thread for WebAudio in
AudioDestination, two racy situnations were observed by ClusterFuzz.

These race conditions become critical especially when the AudioContext
is in the tear-down stage; when the main thread is dumping its member
variables, the rendering thread is still trying to access them.

This CL moves the thread creation logic into Start() and Stop() methods
in AudioDestination. By doing so, the thread is always be in sync with
the associated audio device and the thread can be safely deleted when
the AudioContext goes away.

BUG= 716358 ,  716945 
TEST=(The local TSAN/ASAN passed the repro test cases.)

Review-Url: https://codereview.chromium.org/2853923002
Cr-Commit-Position: refs/heads/master@{#468726}

[modify] https://crrev.com/d94da1744907ed1bb90e37756806841609b0cc52/third_party/WebKit/Source/platform/audio/AudioDestination.cpp
[modify] https://crrev.com/d94da1744907ed1bb90e37756806841609b0cc52/third_party/WebKit/Source/platform/audio/AudioDestination.h

ClusterFuzz has detected this issue as fixed in range 468701:468764.

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

Fuzzer: attekett_webaudio_fuzzer
Job Type: windows_asan_chrome
Platform Id: windows

Crash Type: Heap-use-after-free READ 4
Crash Address: 0x0ec27680
Crash State:
  blink::AudioBus::Zero
  blink::AudioBus::CopyFrom
  blink::AudioDestinationHandler::Render
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=467817:467851
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=468701:468764

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


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

Per #11, ClusterFuzz verified the fix.

And $3,500 for this one :-)

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