Assigning to rtoy@ and jbroman@ as one of you is the Blink sheriff and the both seem to be authors of the functions involved in the stack trace. If you are not the correct owners can you help me find one?

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

This is a webaudio problem.

Unable to reproduce this with ToT today on Linux.  I let crash.html run for about 15 minutes.

Oops. I didn't include all of the files in res.zip when testing.  Retesting now.

Crashes in a few seconds with the given stack trace.

Ok, it looks like in all (or most) cases, the document is gone by the time NotifyAudibleAudioStarted is called.  Without that, we can't create the necessary mojom interface.

rtoy@ is this a null-dereference or is something different (use after free, uninitialized memory, etc.)?

I put a print of GetDocument() and it is nil in many cases when running crash.html.

Is it not always NULL? Does it crash when it's not NULL? I ask because I want to know if this is a security bug or not--a NULL dereference is not a security bug if it can be proven that this is always a NULL dereference. But, some uninitialized memory bugs (which *are*security bugs) often present themselves as NULL dereferences but with sufficient control an attacker can convert them into useful attack primitives.

It is not always NULL.  In the case where it is not NULL, I don't see any asan crashes (after putting a test to only do stuff if GetDocument() is not NULL).

I do not understand why GetDocument() is null but the audio context is alive and the task scheduler can still schedule tasks from the audio thread to the main thread.

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

commit 2a51e23f79734c553c839442ed0c795929bf16e8
Author: Raymond Toy <rtoy@chromium.org>
Date: Fri Sep 14 19:35:05 2018

Make sure document exists before creating a mojom inteface

When the document goes away while the audio thread is running and
trying to notify the document that audible audio has started, we can't
create the necessary mojom interface.  Just return because the
document is gone.

Bug:  882734 , 882639
Change-Id: I168318fb0c44ceb564edeee223aa5f7ee46d43ef
Reviewed-on: https://chromium-review.googlesource.com/1220568
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591436}
[modify] https://crrev.com/2a51e23f79734c553c839442ed0c795929bf16e8/third_party/blink/renderer/modules/webaudio/audio_context.cc

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

commit 8684b801e5ff50ea1db2ae21484521aaa9ef2514
Author: Raymond Toy <rtoy@chromium.org>
Date: Tue Sep 18 21:55:54 2018

Make sure document exists before creating a mojom inteface

When the document goes away while the audio thread is running and
trying to notify the document that audible audio has started, we can't
create the necessary mojom interface.  Just return because the
document is gone.

Bug:  882734 , 882639
Change-Id: I168318fb0c44ceb564edeee223aa5f7ee46d43ef
Reviewed-on: https://chromium-review.googlesource.com/1220568
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#591436}(cherry picked from commit 2a51e23f79734c553c839442ed0c795929bf16e8)
Reviewed-on: https://chromium-review.googlesource.com/1232204
Reviewed-by: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#509}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/8684b801e5ff50ea1db2ae21484521aaa9ef2514/third_party/blink/renderer/modules/webaudio/audio_context.cc

This should be fixed now since it looks like the same problem as issue 882639.

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

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

Great, derestricting this as a security bug because it's just a NULL ptr dereference.

Unable to reproduce the issue on ubuntu 17.10 using chrome reported version #71.0.3542.0. Observed that on running ./chrome crash.html, the video blinked continuously without any content and no crash is seen. Same behaviour is seen in chrome version #70.0.3538.35 also.
Attached a screen cast for reference.
Note: Tried testing with both chromium and chrome builds.

rtoy@ - Could you please check the attached screen cast and please help us in verifying the fix.

Thanks...!!

Deleted: 882734.webm 673 KB

	882734.webm 673 KB View Download

Yes, the screen cast is what I see.  I don't see crashes anymore. I tested this with ToT chromium from just now (71.0.3563.0).