Package: libaudiofile0 Version: 0.2.6-6 Severity: critical Today, the Music Player Daemon project received a bug report from Anton Khirnov: MPD crashed when attempting to play a WAV file. "file" says:
RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, stereo 44100 Hz The MPD bug report: http://musicpd.org/mantis/view.php?id=1915 The test file: http://filebin.ca/meqmyu/max_theme.wav 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, coefficient[0]); *decoded++ = newSample; Valgrind output: ==4680== Invalid write of size 2 ==4680== at 0x8CF0478: ms_adpcm_run_pull (msadpcm.c:194) ==4680== by 0x8CEAF75: _AFpull (modules.c:111) ==4680== by 0x8CF11A3: int2rebufferf2vrun_pull (rebuffer.template:409) ==4680== by 0x8CDE4ED: afReadFrames (data.c:228) ==4680== by 0x435EBA: audiofile_streamdecode (audiofile_plugin.c:159) ==4680== by 0x4145A2: decoder_stream_decode (decoder_thread.c:49) ==4680== by 0x414A5C: decoder_run (decoder_thread.c:189) ==4680== by 0x414B7B: decoder_task (decoder_thread.c:214) ==4680== by 0x72E0453: g_thread_create_proxy (gthread.c:635) ==4680== by 0x62CBFC6: start_thread (pthread_create.c:297) ==4680== by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so) ==4680== Address 0x15a66de8 is 0 bytes after a block of size 4,096 alloc'd ==4680== at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==4680== by 0x8CDF96A: _af_malloc (util.c:122) ==4680== by 0x8CEEEBA: _AFsetupmodules (modules.c:2539) ==4680== by 0x8CDE151: afGetFrameCount (format.c:218) ==4680== by 0x435CDD: audiofile_streamdecode (audiofile_plugin.c:141) ==4680== by 0x4145A2: decoder_stream_decode (decoder_thread.c:49) ==4680== by 0x414A5C: decoder_run (decoder_thread.c:189) ==4680== by 0x414B7B: decoder_task (decoder_thread.c:214) ==4680== by 0x72E0453: g_thread_create_proxy (gthread.c:635) ==4680== by 0x62CBFC6: start_thread (pthread_create.c:297) ==4680== by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so) 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 occurs. Severity "critical" because this is may be used for a remote DoS attack on software like MPD. I did not investigate whether it is possible to inject code this way. Chances are good, since arbitrary amounts of heap can be overwritten. Both Debian Etch and Lenny are affected. Solution: don't use libaudiofile. Change libaudiofile to allocate the correct buffer size. Add buffer size checks to libaudiofile. Regards, Max Kellermann -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
