[x264-devel] Fwd: x264 heap-buffer-overflow inside x264_cli_plane_copy

[BugMaster]

On Sat, 2 Feb 2019 11:44:45 +0800, Hongxu Chen wrote:
> Dear developers,


>     I reported an x264 crash issue to ffmpeg security and Michael
> Niedermayer suggests I should only report ffmpeg issues by running
> ffmpeg cli. Since I was not able to reproduce this with ffmpeg
> libx264, I forward the following to this mailing list instead.


> Best Regards,
> Hongxu


> ---------- Forwarded message ---------
> From: Hongxu Chen <leftcopy.chx at gmail.com>
> Date: Fri, Feb 1, 2019 at 11:42 AM
> Subject: x264 heap-buffer-overflow inside x264_cli_plane_copy
> To:  <ffmpeg-security at ffmpeg.org>



> Hi,


>     (I followed https://www.videolan.org/developers/x264.html about
> the crash bugs and came here; forgive me if I came to the wrong place.)


>     We found x264 may have a heap-buffer-overflow issue. Here is an
> error reported by AddressSanitizer when executing "x264 --threads 1
> --quiet --output /dev/null hbo_internal.c:34_2".


> =================================================================
> ==66950==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x7f32d900d82f at pc 0x0000004bf7e1 bp 0x7ffd9ba0ac70 sp 0x7ffd9ba0a420
> READ of size 1408 at 0x7f32d900d82f thread T0
>     #0 0x4bf7e0 in __asan_memcpy
> (/home/ubuntu/work/x264/x264-asan/install/bin/x264+0x4bf7e0)
>     #1 0x525a7d in x264_cli_plane_copy
> /home/ubuntu/work/x264/x264-asan/filters/video/internal.c:34:9
>     #2 0x525dec in x264_cli_pic_copy
> /home/ubuntu/work/x264/x264-asan/filters/video/internal.c:56:9
>     #3 0x529fb8 in get_frame
> /home/ubuntu/work/x264/x264-asan/filters/video/fix_vfr_pts.c:100:13
>     #4 0x512ff7 in encode
> /home/ubuntu/work/x264/x264-asan/x264.c:1980:13
>     #5 0x50ea89 in main_internal
> /home/ubuntu/work/x264/x264-asan/x264.c:388:15
>     #6 0x5b66cb in x264_stack_align
> (/home/ubuntu/work/x264/x264-asan/install/bin/x264+0x5b66cb)


> 0x7f32d900d82f is located 0 bytes to the right of 405551-byte
> region [0x7f32d8faa800,0x7f32d900d82f)
> allocated by thread T0 here:
>     #0 0x4d51f8 in __interceptor_posix_memalign
> (/home/ubuntu/work/x264/x264-asan/install/bin/x264+0x4d51f8)
>     #1 0x7f32f0215762 in av_malloc
> (/usr/lib/x86_64-linux-gnu/libavutil.so.55+0x31762)


> SUMMARY: AddressSanitizer: heap-buffer-overflow
> (/home/ubuntu/work/x264/x264-asan/install/bin/x264+0x4bf7e0) in __asan_memcpy
> Shadow bytes around the buggy address:
>   0x0fe6db1f9ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0fe6db1f9ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0fe6db1f9ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0fe6db1f9ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0fe6db1f9af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>>0x0fe6db1f9b00: 00 00 00 00 00[07]fa fa fa fa fa fa fa fa fa fa
>   0x0fe6db1f9b10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0fe6db1f9b20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0fe6db1f9b30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0fe6db1f9b40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0fe6db1f9b50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07 
>   Heap left redzone:       fa
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb  ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
> ==66950==ABORTING
> [1]    66950 abort      ~/work/x264/x264-asan/install/bin/x264
> --threads 1 --quiet --output /dev/null


> The crash site is a call to memcpy however it seems that it should
> have been wrong earlier (values of "w"/"h").
> Plus, there seem some non-deterministic behaviors since each time
> it may crash at different iterations of call to memcpy.

> Best Regards,
> Hongxu

Hi.

As I am on Windows I can't use AddressSanitizer to reproduce it but
from attached report it looks like lavf filter gets incorrect frame
resolution or buffers allocated inside libavcodec. If it is so I doubt
we can do anything at our side to fix it.
As I understand your input is fuzzing tests which detected as h263
format. I am not sure how stable is ffmpeg's h263 decoder during
bitstream errors.

Anyway it need more debugging from someone who can check with
AddressSanitizer.