Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 253481 (CVE-2008-5824) - media-libs/audiofile: heap corruption while reading .wav files (CVE-2008-5824)
Summary: media-libs/audiofile: heap corruption while reading .wav files (CVE-2008-5824)
Alias: CVE-2008-5824
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: B2 [noglsa]
Depends on:
Reported: 2009-01-02 21:48 UTC by Matti Bickel (RETIRED)
Modified: 2013-09-03 02:45 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Matti Bickel (RETIRED) gentoo-dev 2009-01-02 21:48:26 UTC

"Today, the Music Player Daemon project received a bug report from
Anton Khirnov: MPD crashed when attempting to play a WAV file.  "file"

 RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, stereo 44100

The MPD bug report:

The test file:

Turns out that this is a bug in libaudiofile.  When attempting to
decode the file, libaudiofile writes past the buffer in msadpcm.c:194

  code = *encoded >> 4;
  newSample = ms_adpcm_decode_sample(state[0], code,
  *decoded++ = newSample;
A quick look at the code revealed that the allocated buffer size
depended on the following formula:

  bufsize = outc->nframes * _af_format_frame_size(&outc->f, AF_TRUE);

outc->nframes basically comes from _AF_ATOMIC_NVFRAMES (1024), because
the msadpcm module does not implement the max_pull callback.  This
results in a 4096 byte allocation in modules.c:2539 (frame size is 4).

In ms_adpcm_decode_block(), msadpcm->samplesPerBlock is set to 2036
(unverified value from the input file header).  outputLength is 8144,
which obviously does not fit into the allocated 4096 byte buffer.

I could reproduce the same crash with "normalize-audio max_theme.wav".
The real crash happens after closing the file, probably due to heap
corruption.  valgrind notices the problem before the crash actually

To me this sounds like an application crash with a possible security hole due to the heap overflow. But i'm no expert on this.
Comment 1 Matti Bickel (RETIRED) gentoo-dev 2009-01-02 21:51:27 UTC
There's no fix yet, if i get the debian bug report correctly. Can we provide/work with the debian folks on one?
Comment 2 Matti Bickel (RETIRED) gentoo-dev 2009-01-03 17:56:18 UTC
Was assigned CVE-2008-5824
Comment 3 Daniel Gryniewicz (RETIRED) gentoo-dev 2009-01-07 02:58:20 UTC
There's now a patch, but he says it needs more work.
Comment 5 Robert Buchholz (RETIRED) gentoo-dev 2009-03-04 18:08:20 UTC
.. which still backtraces...

$ normalize max_theme.wav
Computing levels...
 max_theme.wav     100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00)
Applying adjustment of -3.26dB to max_theme.wav...
*** glibc detected *** normalize: corrupted double-linked list: 0x0000000000c5f310 ***
======= Backtrace: =========
Comment 6 Pacho Ramos gentoo-dev 2012-05-01 19:54:37 UTC
Upstream bug (closed as fixed):
Comment 7 Chris Reffett (RETIRED) gentoo-dev Security 2013-09-03 02:45:06 UTC
CVE says that it only affects audiofile-0.2.6. Long removed. Closing noglsa.