Tested on: OS: Ubuntu 12.04 Firefox: ASAN opt-build from https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-asan/1369426802/ ASAN-report: ==27367== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8b7696050 at pc 0x7fd8df363567 bp 0x7fd8b926d3f0 sp 0x7fd8b926d3e8 WRITE of size 1 at 0x7fd8b7696050 thread T25 #0 0x7fd8df363566 in mozilla::AudioNodeStream::ObtainInputBlock(mozilla::AudioChunk&, unsigned int) /builds/slave/m-cen-l64-asan-000000000000000/build/content/media/AudioNodeStream.cpp:374 #1 0x7fd8df363d45 in mozilla::AudioNodeStream::ProduceOutput(long, long) /builds/slave/m-cen-l64-asan-000000000000000/build/content/media/AudioNodeStream.cpp:415 #2 0x7fd8df3d1a53 in mozilla::MediaStreamGraphImpl::ProduceDataForStreamsBlockByBlock(unsigned int, long, long) /builds/slave/m-cen-l64-asan-000000000000000/build/content/media/MediaStreamGraph.cpp:937 #3 0x7fd8df3e3bd5 in mozilla::(anonymous namespace)::MediaStreamGraphThreadRunnable::Run() /builds/slave/m-cen-l64-asan-000000000000000/build/content/media/MediaStreamGraph.cpp:1163 . . .

If channelCount is 4294967295 we are crashing with an OOM error but if channelCount is 519910189000000 we are crashing with a heap-buffer-overflow. The WebAudio spec says channelCount is of type unsigned long.

(In reply to Christoph Diehl [:cdiehl] from comment #1) > If channelCount is 4294967295 we are crashing with an OOM error but if > channelCount is 519910189000000 we are crashing with a heap-buffer-overflow. > The WebAudio spec says channelCount is of type unsigned long. So this value is not [Clamp] or [EnforceRange], which means that a large value is converted down to a uint32_t using the modulo operation (returning 102851904 here), which is probably not what we want... I need to raise this issue on the public-audio list, but we have a bug here no matter how we handle this.

The bug here is caused because 102851904*sizeof(float)*WEBAUDIO_BLOCK_SIZE is more than what fits in a 32-bit integer, so we overflow and allocate a buffer too small in AllocateAudioBlock. I think we should just limit the channel count uniformly everywhere.

With the test case from bug 876207.

Does this affect branches other than trunk or this this disabled on 22 and 23 and not out on 21?

(In reply to Al Billings [:abillings] from comment #10) > Does this affect branches other than trunk or this this disabled on 22 and > 23 and not out on 21? Like all Web Audio bugs, it affects trunk, and 23, until 23 goes to beta.

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.