Issue metadata
Sign in to add a comment
|
Bad-cast to blink::WebAudioSourceProvider from invalid vptr in blink::HTMLMediaElement::AudioSourceProviderImpl::Wrap |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6534580627308544 Fuzzer: inferno_layout_test_unmodified Job Type: linux_ubsan_vptr_content_shell_drt Platform Id: linux Crash Type: Bad-cast Crash Address: 0x2f052e683e10 Crash State: Bad-cast to blink::WebAudioSourceProvider from invalid vptr blink::HTMLMediaElement::AudioSourceProviderImpl::Wrap blink::HTMLMediaElement::StartPlayerLoad Sanitizer: undefined (UBSAN) Recommended Security Severity: High Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_content_shell_drt&range=527199:527221 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6534580627308544 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Mar 16 2018
,
Mar 17 2018
chcunningham, any chance this could be related to https://chromium-review.googlesource.com/851066 (in the regression range)?
,
Mar 17 2018
No, I don't see a way. The linked CL makes a small change to WebM parsing for media playback using MediaSource. This test appears to just use plain old
<audio src="some.file">, judging by this line in the fuzz-130.html
audio.src = findMediaFile("audio", "content/test");
So the MSE code paths are not involved.
,
Mar 17 2018
,
Mar 17 2018
,
Mar 19 2018
I don't see any way for the WebAudioSourceProvider* pointer in this object to end up having a type other than WebAudioSourceProvider (it's only assigned to a variable with type WebAudioSourceProvider*). Could there have been an object smash where arbitrary bytes have been written into the pointer member? That's pretty concerning, but that being said, there's nothing really obvious in the blame list for this, and the bit of code that is triggering this failure hasn't changed since 2015 (with the Blink reformat the only change in the interim). I can easily reproduce this crash on tip of tree as well as the reported range using the clusterfuzz reproduce tool linked in the report. +cc some Blink>Media people who've worked on this file lately, can you please investigate this further?
,
Mar 19 2018
ClusterFuzz keeps using internal methods that put the media elements in an unexpected state. These methods can't be used by websites so it's not an issue. I will contact the clusterfuzz team to see if there is something we can do as it's not the first occurence.
,
Mar 19 2018
,
Mar 26 2018
ClusterFuzz testcase 6534580627308544 is still reproducing on tip-of-tree build (trunk). If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase. Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.
,
Jun 25 2018
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 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ClusterFuzz
, Mar 16 2018Labels: Test-Predator-Auto-Components