Opened 11 years ago

Closed 11 years ago

#1137 closed defect (duplicate)

Valgrind reports Invalid Read in mov_build_index (demux_mov.c:237)

Reported by: nstockma@… Owned by: r_togni@…
Priority: normal Component: demuxer
Version: HEAD Severity: normal
Keywords: Cc: catchconv-bugreports@…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

Here's an mp4 file where Valgrind reports an Invalid Read of size 4. The mp4
file (39-13.mp4) can be found inside the .tgz archive at the URL
above. The bug is easily reproducible.

Note that this bug also causes Mplayer to crash.

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

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

This bug appears similar to Bug 1125 but the stack traces are not identical so I'm reporting it in case it is a separate bug.

To reproduce:
wget http://www.metafuzz.com/testcases/600740-39-2280040305-InvalidWrite.tgz
tar xzfv 600740-39-2280040305-InvalidWrite?.tgz
valgrind mplayer 39-13.mp4

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

user@debian:~/Desktop$ valgrind mplayer 39-13.mp4
==957== Memcheck, a memory error detector.
==957== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==957== Using LibVEX rev 1854, a library for dynamic binary translation.
==957== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks? LLP.
==957== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==957== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==957== For more details, rerun with: -v
==957==
MPlayer dev-SVN-r27243-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 39-13.mp4.
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x863c670]Could not find codec parameters (Data: 0x0000)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x863c670]Could not find codec parameters (Audio: mp4a / 0x6134706D, 44100 Hz, stereo)
LAVF_header: av_find_stream_info() failed
Quicktime/MOV file format detected.
* constant samplesize & variable duration not yet supported! *
Contact the author if you have such sample file!
Warning! pts=-148710222 length=4014080
MOV: durmap and chunkmap sample count differ (1863309243 vs 268439408)
MOV: durmap or chunkmap bigger than sample count (1863309243 vs 3952)
======================================================================================
==957== Invalid write of size 4
==957== Stack hash: 2758727640
==957== at 0x81394B0: mov_build_index (demux_mov.c:237)
==957== by 0x813AA46: lschunks (demux_mov.c:1312)
==957== by 0x813C305: mov_read_header (demux_mov.c:1931)
==957== by 0x811E2BE: demux_open_stream (demuxer.c:864)
==957== by 0x811E591: demux_open (demuxer.c:991)
==957== by 0x807792E: main (mplayer.c:3238)
==957== Address 0x0 is not stack'd, malloc'd or (recently) free'd

MPlayer interrupted by signal 11 in module: demux_open

  • 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.

==957==
==957== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 19 from 1)
==957== malloc/free: in use at exit: 110,376 bytes in 2,187 blocks.
==957== malloc/free: 2,335 allocs, 148 frees, 1,453,944 bytes allocated.
==957== For counts of detected errors, rerun with: -v
==957== searching for pointers to 2,187 not-freed blocks.
==957== checked 2,843,184 bytes.
==957==
==957== LEAK SUMMARY:
==957== definitely lost: 0 bytes in 0 blocks.
==957== possibly lost: 0 bytes in 0 blocks.
==957== still reachable: 110,376 bytes in 2,187 blocks.
==957== suppressed: 0 bytes in 0 blocks.
==957== Rerun with --leak-check=full to see details of leaked memory.

The following is a backtrace using gdb:

(gdb) bt
#0 mov_build_index (trak=0x898f5b0, timescale=600)

at libmpdemux/demux_mov.c:237

#1 0x0813aa47 in lschunks (demuxer=0x898d800, level=0, endpos=6117520,

trak=0x0) at libmpdemux/demux_mov.c:1312

#2 0x0813c306 in mov_read_header (demuxer=0x898d800)

at libmpdemux/demux_mov.c:1931

#3 0x0811e2bf in demux_open_stream (stream=0x898e188,

file_format=<value optimized out>, force=0, audio_id=-1, video_id=-1,
dvdsub_id=-2, filename=0x89843f0 "../Desktop/39-13.mp4")
at libmpdemux/demuxer.c:864

#4 0x0811e592 in demux_open (vs=0x898e188, file_format=0, audio_id=-1,

video_id=-1, dvdsub_id=-2, filename=0x89843f0 "../Desktop/39-13.mp4")
at libmpdemux/demuxer.c:991

#5 0x0807792f in main (argc=4, argv=0xbfafd9b4) at mplayer.c:3238
(gdb) disass $pc-32 $pc+32
Dump of assembler code from 0x8139490 to 0x81394d0:
0x08139490 <mov_build_index+608>: xor %eax,%eax
0x08139492 <mov_build_index+610>: shl $0x4,%edx
0x08139495 <mov_build_index+613>: mov %edi,0xffffffa4(%ebp)
0x08139498 <mov_build_index+616>: jmp 0x81394ab <mov_build_index+635>
0x0813949a <mov_build_index+618>: lea 0x0(%esi),%esi
0x081394a0 <mov_build_index+624>: mov 0x8(%ebp),%edi
0x081394a3 <mov_build_index+627>: add $0x10,%edx
0x081394a6 <mov_build_index+630>: cmp %ebx,0x54(%edi)
0x081394a9 <mov_build_index+633>: jle 0x81394c5 <mov_build_index+661>
0x081394ab <mov_build_index+635>: mov 0xffffffa4(%ebp),%edi
0x081394ae <mov_build_index+638>: inc %eax
0x081394af <mov_build_index+639>: inc %ebx
0x081394b0 <mov_build_index+640>: mov %esi,(%edi,%edx,1)
0x081394b3 <mov_build_index+643>: mov 0x4(%ecx),%edi
0x081394b6 <mov_build_index+646>: mov 0xffffff94(%ebp),%ecx
0x081394b9 <mov_build_index+649>: add %edi,%esi
0x081394bb <mov_build_index+651>: mov 0x8(%ebp),%edi
0x081394be <mov_build_index+654>: add 0x70(%edi),%ecx
0x081394c1 <mov_build_index+657>: cmp %eax,(%ecx)
0x081394c3 <mov_build_index+659>: ja 0x81394a0 <mov_build_index+624>
0x081394c5 <mov_build_index+661>: incl 0xffffffe4(%ebp)
0x081394c8 <mov_build_index+664>: mov 0x8(%ebp),%edx
---Type <return> to continue, or q <return> to quit---
0x081394cb <mov_build_index+667>: mov 0xffffffe4(%ebp),%eax
0x081394ce <mov_build_index+670>: cmp %eax,0x6c(%edx)
End of assembler dump.
(gdb) info all-registers
eax 0x1 1
ecx 0x898f6f0 144242416
edx 0x0 0
ebx 0x1 1
esp 0xbfafc3f0 0xbfafc3f0
ebp 0xbfafc498 0xbfafc498
esi 0x0 0
edi 0x0 0
eip 0x81394b0 0x81394b0 <mov_build_index+640>
eflags 0x210202 [ IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
st0 0 (raw 0x00000000000000000000)
st1 0 (raw 0x00000000000000000000)
st2 0 (raw 0x00000000000000000000)
st3 0 (raw 0x00000000000000000000)
st4 0 (raw 0x00000000000000000000)
st5 1 (raw 0x3fff8000000000000000)
st6 44100 (raw 0x400eac44000000000000)
---Type <return> to continue, or q <return> to quit---
st7 91.022222222222225695986708160489798 (raw 0x4005b60b60b60b60b800)
fctrl 0x37f 895
fstat 0x21 33
ftag 0xffff 65535
fiseg 0x73 115
fioff 0xb7e55326 -1209707738
foseg 0x7b 123
fooff 0xbfafa328 -1079008472
fop 0x55c 1372
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
---Type <return> to continue, or q <return> to quit---

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},

v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},

uint128 = 0x00000000000000000000000000000000}

mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
mm0 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,

0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}

mm1 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
---Type <return> to continue, or q <return> to quit---

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 2280040305).

Let me know if I can provide more information.

Change History (2)

comment:1 Changed 11 years ago by nstockma@…

Mistake: In the summary it should say that Valgrind reports Invalid *Write* rather than Invalid Read.

comment:2 Changed 11 years ago by reimar

  • Resolution set to duplicate
  • Status changed from new to closed

No, but it is a duplicate of 1113. It does not crash in the same line, but the "responsible" code/the place that would need a check is the same.

* This bug has been marked as a duplicate of bug 1113 *

Note: See TracTickets for help on using tickets.