OOM causes a browser crash in decodeAudioData.

NEW
Unassigned

Status

()

P5
normal
4 years ago
a year ago

People

(Reporter: jujjyl, Unassigned)

Tracking

({crash})

35 Branch
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(firefox34 affected, firefox36 affected)

Details

(crash signature)

(Reporter)

Description

4 years ago
This bug was filed from the Socorro interface and is 
report bp-10cd3d9c-df43-44c7-8528-d0f112140911.
=============================================================

Repeatedly calling decodeAudioData in low memory situations can cause the browser to hard-crash to desktop, instead of gracefully failing the decodeAudioData operation.

Another such report in https://crash-stats.mozilla.com/report/index/1c439e58-9635-497e-964c-c25d92140911.

Looking at the code at http://hg.mozilla.org/mozilla-central/annotate/152ef25e89ae/content/media/AudioCompactor.h#l44 , it unconditionally calls 'new AudioDataValue[samples]' without being prepared for an OOM situation (?).

Comment 1

4 years ago
Not security-sensitive.

The allocation size is 28672, which we consider "small" for the purposes of OOM handling. Is "samples" a user-controlled value which can be any size?
Group: core-security
Flags: needinfo?(jujjyl)
CCing Ben Kelly, who wrote this. Ben, do you know why we are OOMing here ?
(Reporter)

Comment 3

4 years ago
I don't know, but I believe so. This is occurring in an application that repeatedly loops to load new audio clips and perform decodeAudioData. I am assuming it is the length of the user-submitted audio clip.
(Reporter)

Updated

4 years ago
Flags: needinfo?(jujjyl)

Comment 4

4 years ago
If this is a user-controlled buffer size, it should be using fallible malloc and null-checking appropriately. This probably means using

  new (fallible_t()) AudioDataValue[samples]
No, it's not user-controlled. This is crashing in the implementation the mp3 decoder, on a single decoded frame, hence why the alloc that provokes the OOM is so small.

The user-facing API (decodeAudioData) appropriately uses fallible malloc [0] if the result ends up too big, and calls the error callback, as it should.

http://hg.mozilla.org/mozilla-central/annotate/152ef25e89ae/content/media/webaudio/MediaBufferDecoder.cpp#l309
Ubuntu 14.04 32-bit   Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0

Encountered the crash https://crash-stats.mozilla.com/report/index/bp-eea8d3f5-060a-4e7d-84df-557192141028 using Firefox 34 beta 4 while playing a youtube video in one tab and trying to play several videos from vimeo.com in another tab.

I couldn't reproduce the bug afterwards, but please let me know if I can help with anything.
status-firefox34: --- → affected
status-firefox36: --- → affected
This should be fixed in the underlying decoders.
Component: Web Audio → Video/Audio
Component: Audio/Video → Audio/Video: Playback

Updated

3 years ago
Component: Audio/Video: Playback → Web Audio
Severity: critical → normal
Priority: -- → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.