Valgrind reports Invalid Read in decode_audio (ad_imaadpcm.c:263)

[nstockma@…]

Here's a wav file where Valgrind reports an invalid read of size 2. The wav file (50-short-dying.wav) can be found inside the .tgz archive at the URL above. The bug is easily reproducible. Note that it does not cause MPlayer to crash.

I confirmed that this bug is reproducible on Linux OS, Debian x32 with the
following subversion of MPlayer: dev-SVN-r27137-4.1.2

I used a 32-bit Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz.

To reproduce:

wget ​http://www.metafuzz.com/testcases/441989-50-1253818897-InvalidRead.tgz
tar xzfv 441989-50-1253818897-InvalidRead.tgz
valgrind mplayer 50-short-dying.wav

Here is the output from valgrind and mplayer on my machine:

user@debian:~/Desktop/BUGS!/8897_InvRead$ valgrind mplayer 50-short-dying.wav
==22107== Memcheck, a memory error detector.
==22107== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==22107== Using LibVEX rev 1854, a library for dynamic binary translation.
==22107== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==22107== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==22107== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==22107== For more details, rerun with: -v
==22107==
MPlayer dev-SVN-r27137-4.1.2 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (Family: 6, Model: 15, Stepping: 6)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Playing 50-short-dying.wav.
Audio file file format detected.
==========================================================================
Opening audio decoder: [imaadpcm] IMA ADPCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->176400)
Selected audio codec: [imaadpcm] afm: imaadpcm (IMA ADPCM)
==========================================================================
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
==22107== Invalid read of size 2
==22107== Stack hash: 1106705545
==22107== at 0x80D75EC: decode_audio (ad_imaadpcm.c:263)
==22107== by 0x80D8394: decode_audio (dec_audio.c:383)
==22107== by 0x8075D19: main (mplayer.c:2044)
==22107== Address 0x42e6d44 is 0 bytes after a block of size 4 alloc'd
==22107== Stack hash: 1660931823
==22107== at 0x401C882: memalign (vg_replace_malloc.c:460)
==22107== by 0x80D897C: init_audio (dec_audio.c:77)
==22107== by 0x80D8E28: init_best_audio_codec (dec_audio.c:270)
==22107== by 0x8073FA8: reinit_audio_chain (mplayer.c:1585)
==22107== by 0x8075951: main (mplayer.c:3583)
==22107==
==22107== Invalid read of size 1
==22107== Stack hash: 1106738401
==22107== at 0x80D7604: decode_audio (ad_imaadpcm.c:265)
==22107== by 0x80D8394: decode_audio (dec_audio.c:383)
==22107== by 0x8075D19: main (mplayer.c:2044)
==22107== Address 0x42e6d46 is 2 bytes after a block of size 4 alloc'd
==22107== Stack hash: 1660931823
==22107== at 0x401C882: memalign (vg_replace_malloc.c:460)
==22107== by 0x80D897C: init_audio (dec_audio.c:77)
==22107== by 0x80D8E28: init_best_audio_codec (dec_audio.c:270)
==22107== by 0x8073FA8: reinit_audio_chain (mplayer.c:1585)
==22107== by 0x8075951: main (mplayer.c:3583)
A: 0.0 (unknown) of 0.0 (unknown) ??,?%

Exiting... (End of file)
==22107==
==22107== ERROR SUMMARY: 18432 errors from 2 contexts (suppressed: 17 from 1)
==22107== malloc/free: in use at exit: 32,908 bytes in 12 blocks.
==22107== malloc/free: 11,548 allocs, 11,536 frees, 2,140,186 bytes allocated.
==22107== For counts of detected errors, rerun with: -v
==22107== searching for pointers to 12 not-freed blocks.
==22107== checked 2,743,520 bytes.
==22107==
==22107== LEAK SUMMARY:
==22107== definitely lost: 0 bytes in 0 blocks.
==22107== possibly lost: 0 bytes in 0 blocks.
==22107== still reachable: 32,908 bytes in 12 blocks.
==22107== suppressed: 0 bytes in 0 blocks.
==22107== Rerun with --leak-check=full to see details of leaked memory.

I have not attempted to review this bug to determine whether it represents a
security risk or not.

This bug was found using the zzuf fuzzer. It was found as part of the
SUPERB-TRUST 2008 project ( see ​http://www.truststc.org/superb/ ) and the
metafuzz project ( see ​http://metafuzz.com/, stack hash 3982677856 ).

Let me know if I can provide more information.

[nstockma@…]

Mistake in last line of my description:

If you would like to look up this bug on the metafuzz page (​http://metafuzz.com/) the stack hash for it is actually 1253818897.

[reimar]

Probably fixed in SVN r27145. Server is down, so I could not download the sample.

[reimar]

* Bug 1122 has been marked as a duplicate of this bug. *

[reimar]

.