Valgrind reports invalid read in mp_decode_layer3()

[daw-bugzilla@…]

Here's a mp3 file where Valgrind reports an invalid read of 4 bytes at an invalid memory location. The mp3 file (534-snippet3.mp3) can be found inside the .tgz archive at the URL above. The bug is easily reproducible.

I confirmed that this bug is present in the latest version of mplayer (svn head, revision 27097, libavformat revision 13799).

To reproduce:

wget ​http://www.metafuzz.com/testcases/979452-534-2960080539-InvalidRead.tgz
tar xzvf 979452-534-2960080539-InvalidRead.tgz
valgrind mplayer 534-snippet3.mp3

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

$ valgrind ./mplayer/mplayer 534-snippet3.mp3
==29814== Memcheck, a memory error detector.
==29814== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==29814== Using LibVEX rev 1732, a library for dynamic binary translation.
==29814== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==29814== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==29814== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==29814== For more details, rerun with: -v
==29814==
MPlayer dev-SVN-r27097-4.1.2 (C) 2000-2008 MPlayer Team
CPU: AMD Athlon(tm) 64 Processor 3200+ (Family: 15, Model: 12, Stepping: 0)
3DNow supported but disabled
3DNowExt supported but disabled
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Playing 534-snippet3.mp3.
libavformat file format detected.
==29814== Invalid read of size 4
==29814== at 0x8053A9: mp_decode_layer3 (bitstream.h:658)
==29814== by 0x806094: mp_decode_frame (mpegaudiodec.c:2305)
==29814== by 0x807B84: decode_frame (mpegaudiodec.c:2401)
==29814== by 0x69E7A7: avcodec_decode_audio2 (utils.c:927)
==29814== by 0x62172A: av_find_stream_info (utils.c:1758)
==29814== by 0x583BA1: demux_open_lavf (demux_lavf.c:466)
==29814== by 0x4F7DC9: demux_open_stream (demuxer.c:864)
==29814== by 0x4F8124: demux_open (demuxer.c:991)
==29814== by 0x44021B: main (mplayer.c:3238)
==29814== Address 0x9CCCC72 is not stack'd, malloc'd or (recently) free'd
invalid new backstep -248
[lavf] Audio stream found, -aid 0
Clip info:

name: Exterminate Annihil�te Destroy
author: Rotersand $
comments: Amazon.com Song ID: 20274780
album: Exterminate Annihilate Destroy
genre: Classic Rock

==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
unhandled opc_aux = 0x 3
first_opcode == 0xDF
vex amd64->IR: unhandled instruction bytes: 0xDF 0x9F 0x0 0x2
==29814== valgrind: Unrecognised instruction at address 0x5FE616.
==29814== Your program just tried to execute an instruction that Valgrind
==29814== did not recognise. There are two possible reasons for this.
==29814== 1. Your program has a bug and erroneously jumped to a non-code
==29814== location. If you are running Memcheck and you just saw a
==29814== warning about a bad jump, it's probably your program's fault.
==29814== 2. The instruction is legitimate but Valgrind doesn't handle it,
==29814== i.e. it's Valgrind's fault. If you think this is the case or
==29814== you are not sure, please let us know and we'll try to fix it.
==29814== Either way, Valgrind will now raise a SIGILL signal which will
==29814== probably kill your program.

MPlayer interrupted by signal 4 in module: init_audio_codec

• MPlayer crashed by an 'Illegal Instruction'. It usually happens when you run it on a CPU different than the one it was compiled/optimized for. Verify this!
• MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

==29814==
==29814== ERROR SUMMARY: 16 errors from 1 contexts (suppressed: 6 from 1)
==29814== malloc/free: in use at exit: 311,663 bytes in 2,570 blocks.
==29814== malloc/free: 3,052 allocs, 482 frees, 3,055,917 bytes allocated.
==29814== For counts of detected errors, rerun with: -v
==29814== searching for pointers to 2,570 not-freed blocks.
==29814== checked 7,718,872 bytes.
==29814==
==29814== LEAK SUMMARY:
==29814== definitely lost: 0 bytes in 0 blocks.
==29814== possibly lost: 0 bytes in 0 blocks.
==29814== still reachable: 311,663 bytes in 2,570 blocks.
==29814== suppressed: 0 bytes in 0 blocks.
==29814== 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.

I don't know what component this is most relevant to (I don't understand the components) so I guessed.

This is on a x86_64 architecture (Core 2 Duo) on Linux (Fedora Core 8, x86_64, 2.6.24.7-92.fc8 kernel). Let me know if I can provide any more information.

This bug was found using the zzuf fuzzer. This bug was found as part of the metafuzz project; see ​http://metafuzz.com/, stack hash 2960080539.