WebAudio heap-buffer-overflow crash [@mozilla::AudioBlockCopyChannelWithScale]

RESOLVED FIXED in Firefox 24

Status

()

defect
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: posidron, Assigned: padenot)

Tracking

(Blocks 1 bug, 5 keywords)

Trunk
mozilla24
x86_64
macOS
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox22 disabled, firefox23- disabled, firefox24+ fixed, firefox-esr17 unaffected, b2g18 unaffected)

Details

(Whiteboard: [adv-main24-])

Attachments

(2 attachments)

Reporter

Description

6 years ago
Posted file testcase
content/media/AudioNodeEngine.cpp:64

void
AudioBlockCopyChannelWithScale(const float* aInput,
                               float aScale,
                               float* aOutput)
{
  if (aScale == 1.0f) {
*   memcpy(aOutput, aInput, WEBAUDIO_BLOCK_SIZE*sizeof(float));
[...]
}
Reporter

Comment 1

6 years ago
Posted file callstack
Reporter

Comment 2

6 years ago
Please see also: https://bugzilla.mozilla.org/show_bug.cgi?id=876207#c0

This is exactly where my concern is, we are not fixing the root of the problems.

I believe we should add a sanitize checks for the memcpy parameters so that we won't crash there again.
(In reply to Christoph Diehl [:cdiehl] from comment #2)
> Please see also: https://bugzilla.mozilla.org/show_bug.cgi?id=876207#c0
> 
> This is exactly where my concern is, we are not fixing the root of the
> problems.
> 
> I believe we should add a sanitize checks for the memcpy parameters so that
> we won't crash there again.

I don't think that's the case.  We can't check for the length of the buffer because AudioChunk doesn't keep track of that information at all.  We should just make sure we're consistent in keeping track of the number of channels, the offsets, etc.  There's no single root cause for these kinds of bugs, well, besides using an unsafe language!  :-)
Assignee: nobody → paul
Assignee

Comment 5

6 years ago
This does not happen on tip for me, but I can repro on d7c6d6061ab5. Now bisecting to see what "fixed" it, because nothing seem to touch WebAudio in the log.
Paul, can you please check in the test case as a crashtest?

Closing as FIXED for now, for the purpose of tracking the work left.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: needinfo?(paul)
Resolution: --- → FIXED
Assignee

Comment 7

6 years ago
Sure, will do later today.
Flags: needinfo?(paul)
Paul, please add this to the crashtest suite here:

<http://mxr.mozilla.org/mozilla-central/source/content/media/test/crashtests/>

See my recent commits to that directory for examples.  Thanks!
Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.
Component: Video/Audio → Web Audio
Whiteboard: [adv-main24-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.