It is possible to trigger a heap buffer overflow with the ChannelMergerNode of the WebAudio API. The stacktrace was generated with this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.linux-i686.tar.bz2 stacktrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xd5bfeb40 (LWP 13514)] 0xf5057e7b in mozilla::AudioBlockCopyChannelWithScale(float const*, float, float*) () from /test/firefox-2.4.14-nightly-32bit/libxul.so (gdb) bt #0 0xf5057e7b in mozilla::AudioBlockCopyChannelWithScale(float const*, float, float*) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #1 0xf5063524 in mozilla::AudioNodeStream::AccumulateInputChunk(unsigned int, mozilla::AudioChunk const&, mozilla::AudioChunk*, nsTArray<float>*) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #2 0xf5063738 in mozilla::AudioNodeStream::ObtainInputBlock(mozilla::AudioChunk&, unsigned int) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #3 0xf5063dd3 in mozilla::AudioNodeStream::ProcessInput(long long, long long, unsigned int) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #4 0xf506d1d8 in mozilla::MediaStreamGraphImpl::ProduceDataForStreamsBlockByBlock(unsigned int, int, long long, long long) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #5 0xf507df2e in mozilla::MediaStreamGraphImpl::RunThread() () from /test/firefox-2.4.14-nightly-32bit/libxul.so #6 0xf507e2f2 in mozilla::(anonymous namespace)::MediaStreamGraphInitThreadRunnable::Run() () from /test/firefox-2.4.14-nightly-32bit/libxul.so #7 0xf3fb21d2 in nsThread::ProcessNextEvent(bool, bool*) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #8 0xf3f9d605 in NS_ProcessNextEvent(nsIThread*, bool) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #9 0xf444e0d7 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #10 0xf443cc0d in MessageLoop::Run() () from /test/firefox-2.4.14-nightly-32bit/libxul.so #11 0xf424a5cf in nsThread::ThreadFunc(void*) () from /test/firefox-2.4.14-nightly-32bit/libxul.so #12 0xf7b97edb in _pt_root () from /test/firefox-2.4.14-nightly-32bit/libnspr4.so #13 0xf7f9ed4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #14 0xf7d9cbae in clone () from /lib/i386-linux-gnu/libc.so.6

This is the same bug as bug 990794, but with a slightly different test case. The test case is this bug also depends on a bug in the cycle detection code meaning that cycles without a DelayNode are sometimes not muted (when they should be) if the cycle intersects a cycle with a DelayNode. That bug is fixed by the patch remaining in bug 932400. This test case will not overflow with the patches from bug 990794, bug 990868, or bug 932400.

Verifying the fix here requires comparing the crash stacks of before and after builds. The "before" build may not crash at a reliable location but it is likely to be in AudioBlockCopyChannelWithScale. With 32-bit builds, the "after" build should crash in AllocateAudioBlock. 64-bit builds should now eventually crash on OOM.

The output of ASAN builds can also be compared.

Isn't this a straight dupe of bug 990794? Karl didn't have to adjust his patch in any way to account for this test variation.