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 sure what's going on here. Nothing obvious in the blame range.

+ a few Blink people on SW, Oilpan, and WebAudio. Please retriage if you could, thanks!

ClusterFuzz has detected this issue as fixed in range 499699:499749.

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

Fuzzer: inferno_twister_c
Job Type: windows_syzyasan_chrome
Platform Id: windows

Crash Type: Heap-use-after-free READ 1
Crash Address: 0x2c2c2c38
Crash State:
  blink::BaseAudioContext::IsDestinationInitialized
  blink::BaseAudioContext::~BaseAudioContext
  blink::FinalizerTraitImpl<blink::ServiceWorkerClient,1>::Finalize
  
Memory Tool: SYZYASAN

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_syzyasan_chrome&range=498677:498753
Fixed: https://clusterfuzz.com/revisions?job=windows_syzyasan_chrome&range=499699:499749

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

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

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

hongchan@: Do you think this is really fixed? The fixed range doesn't have any webaudio changes.  There are a couple v8 autorolls, though.

Perhaps - I believe this crash was not really originated from WebAudio. We didn't change the code above for a long time. Two possibilities:

1. Something might have changes in GC. (The crash happens when GC kicks in)
2. The issue is super hard to reproduce, so CF gave up and marked it as fixed/verified.

@haraken WDYT?

Yes, I think this is a bug of Oilpan GC.

> Crash Address: 0x2c2c2c38

^^^ This means that we're touching an already freed object.

keishi@: Would you mind taking a look at this?

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