[libav-bugs] [Bug 930] New: libav mp4 ff_thread_report_progress Memory corruption

bugzilla at libav.org bugzilla at libav.org
Thu Mar 10 03:36:43 CET 2016


https://bugzilla.libav.org/show_bug.cgi?id=930

            Bug ID: 930
           Summary: libav mp4  ff_thread_report_progress Memory corruption
           Product: Libav
           Version: 11
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: major
          Priority: ---
         Component: libavcodec
          Assignee: bugzilla at libav.org
          Reporter: riusksk at qq.com

Created attachment 576
  --> https://bugzilla.libav.org/attachment.cgi?id=576&action=edit
poc.mp4

libav avconv tool have a memory corruption when parse mp4 file, which can lead
to crash or possbile exec arbitrary code.

test environment:
1、Ubuntu 14.04.2 LTS x64
2、libav 11.6 (released 2016-2-29)

diff normal file and poc:

(sequenceParameterSetNALUnit[7])
00003a0: 6440 14ff e100 2467 6400 14ac 2ca4 313b  d at ....$gd.. | 00003a0: 6440
14ff e100 2467 6400 14ac 2ca4 393b  d at ....$gd..

(stsz=>entry_size[1])
0000490: 0000 0c00 0000 7c00 0000 4000 0000 1900  ......|...@ | 0000490: 0000
0c00 0000 7c00 0000 0000 0000 1900  ......|....


root at Ubuntu:~/libav-11.6# valgrind avconv -i poc2 -f null -
==13879== Memcheck, a memory error detector
==13879== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==13879== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==13879== Command: avconv -i poc2 -f null -
==13879== 
avconv version 11.6, Copyright (c) 2000-2014 the Libav developers
  built on Mar  6 2016 22:05:09 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
[h264 @ 0x5975480] top block unavailable for requested intra4x4 mode -1 at 0 0
[h264 @ 0x5975480] error while decoding MB 0 0, bytestream 104
[h264 @ 0x5975480] AVC: nal size 54
[h264 @ 0x5975480] no frame!
[h264 @ 0x5975480] AVC: nal size 570357068
[h264 @ 0x5975480] no frame!
[h264 @ 0x5975480] AVC: nal size 799623614
[h264 @ 0x5975480] no frame!
==13879== Invalid read of size 8
==13879==    at 0x1323F08: ff_thread_report_progress (pthread_frame.c:440)
==13879==    by 0xD3A67C: ff_h264_decode_slice_header (h264_slice.c:1441)
==13879==    by 0xC9F595: decode_nal_units (h264.c:1527)
==13879==    by 0xC9F595: h264_decode_frame (h264.c:1782)
==13879==    by 0x14F7141: avcodec_decode_video2 (utils.c:1600)
==13879==    by 0x98E806: try_decode_frame (utils.c:1910)
==13879==    by 0x9A3708: avformat_find_stream_info (utils.c:2276)
==13879==    by 0x5257A5: open_input_file (avconv_opt.c:726)
==13879==    by 0x52913E: open_files (avconv_opt.c:2127)
==13879==    by 0x52913E: avconv_parse_options (avconv_opt.c:2164)
==13879==    by 0x4ED5BE: main (avconv.c:2630)
==13879==  Address 0x258 is not stack'd, malloc'd or (recently) free'd
==13879== 
==13879== 
==13879== Process terminating with default action of signal 11 (SIGSEGV)
==13879==  Access not within mapped region at address 0x258
==13879==    at 0x1323F08: ff_thread_report_progress (pthread_frame.c:440)
==13879==    by 0xD3A67C: ff_h264_decode_slice_header (h264_slice.c:1441)
==13879==    by 0xC9F595: decode_nal_units (h264.c:1527)
==13879==    by 0xC9F595: h264_decode_frame (h264.c:1782)
==13879==    by 0x14F7141: avcodec_decode_video2 (utils.c:1600)
==13879==    by 0x98E806: try_decode_frame (utils.c:1910)
==13879==    by 0x9A3708: avformat_find_stream_info (utils.c:2276)
==13879==    by 0x5257A5: open_input_file (avconv_opt.c:726)
==13879==    by 0x52913E: open_files (avconv_opt.c:2127)
==13879==    by 0x52913E: avconv_parse_options (avconv_opt.c:2164)
==13879==    by 0x4ED5BE: main (avconv.c:2630)
==13879==  If you believe this happened as a result of a stack
==13879==  overflow in your program's main thread (unlikely but
==13879==  possible), you can try to increase the size of the
==13879==  main thread stack using the --main-stacksize= flag.
==13879==  The main thread stack size used in this run was 8388608.
==13879== 
==13879== HEAP SUMMARY:
==13879==     in use at exit: 930,657 bytes in 147 blocks
==13879==   total heap usage: 370 allocs, 223 frees, 1,057,009 bytes allocated
==13879== 
==13879== LEAK SUMMARY:
==13879==    definitely lost: 0 bytes in 0 blocks
==13879==    indirectly lost: 0 bytes in 0 blocks
==13879==      possibly lost: 0 bytes in 0 blocks
==13879==    still reachable: 930,657 bytes in 147 blocks
==13879==         suppressed: 0 bytes in 0 blocks
==13879== Rerun with --leak-check=full to see details of leaked memory
==13879== 
==13879== For counts of detected and suppressed errors, rerun with: -v
==13879== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

In GDB:

Breakpoint 1, ff_h264_decode_slice_header (h=h at entry=0x7ffff7f31040,
h0=h0 at entry=0x7ffff7f31040) at libavcodec/h264_slice.c:1441
1441                        ff_thread_report_progress(&h0->cur_pic_ptr->tf,
INT_MAX,
gdb-peda$ p h0->cur_pic_ptr
$1 = (H264Picture *) 0x0     <========= the null pointer lead to crash
gdb-peda$ p h0->cur_pic_ptr->tf
Cannot access memory at address 0x248
gdb-peda$ c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0x0 
RBX: 0x7ffff7f31040 --> 0x152c480 --> 0xb95060 --> 0xb9293d ("AVCodecContext")
RCX: 0x3 
RDX: 0x1 
RSI: 0x7fffffff 
RDI: 0x248 
RBP: 0x7ffff7f31040 --> 0x152c480 --> 0xb95060 --> 0xb9293d ("AVCodecContext")
RSP: 0x7fffffffd4c8 --> 0x637f6b (<ff_h264_decode_slice_header+3611>:   mov   
esi,DWORD PTR [rbx+0x47ccc])
RIP: 0x7a17d0 (<ff_thread_report_progress>:     mov    rax,QWORD PTR
[rdi+0x10])
R8 : 0x0 
R9 : 0x1 
R10: 0x3 
R11: 0x0 
R12: 0x3 
R13: 0x300 
R14: 0x0 
R15: 0x0
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction
overflow)
[-------------------------------------code-------------------------------------]
   0x7a17c0 <ff_thread_decode_frame+1984>:      mov    eax,0xfffffff4
   0x7a17c5 <ff_thread_decode_frame+1989>:      jmp    0x7a144a
<ff_thread_decode_frame+1098>
   0x7a17ca:    nop    WORD PTR [rax+rax*1+0x0]
=> 0x7a17d0 <ff_thread_report_progress>:        mov    rax,QWORD PTR [rdi+0x10]
   0x7a17d4 <ff_thread_report_progress+4>:      test   rax,rax
   0x7a17d7 <ff_thread_report_progress+7>:      je     0x7a184a
<ff_thread_report_progress+122>
   0x7a17d9 <ff_thread_report_progress+9>:      mov    rcx,QWORD PTR [rax+0x8]
   0x7a17dd <ff_thread_report_progress+13>:     test   rcx,rcx
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd4c8 --> 0x637f6b (<ff_h264_decode_slice_header+3611>:  mov   
esi,DWORD PTR [rbx+0x47ccc])
0008| 0x7fffffffd4d0 --> 0x0 
0016| 0x7fffffffd4d8 --> 0x30 ('0')
0024| 0x7fffffffd4e0 --> 0x7fffffffd540 --> 0x18 
0032| 0x7fffffffd4e8 --> 0xf21f90bb39c59b00 
0040| 0x7fffffffd4f0 --> 0x5bffffd5c0 
0048| 0x7fffffffd4f8 --> 0x1530000 --> 0x1530380 --> 0x152e1d0 -->
0x500902000000 
0056| 0x7fffffffd500 --> 0x152fff0 --> 0x230 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
ff_thread_report_progress (f=0x248, n=0xf7f31040, field=0x1) at
libavcodec/pthread_frame.c:440
440         int *progress = f->progress ? (int*)f->progress->data : NULL;

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libav.org/pipermail/libav-bugs/attachments/20160310/e4a5e27f/attachment.html>


More information about the libav-bugs mailing list