ffmpeg segfaults on quicktime files with large samples

[Bruce]

Summary of the bug:

I am trying to parse a large QuickTime video file with ffmpeg. I hit a segmentation fault in this case. I have reproduced this with the latest code. I am unable to share the video file is it belongs to.a customer.

Here is the command line:

./ffmpeg -i ../../vid1.mov
ffmpeg version N-103056-g4ff73add5d Copyright (c) 2000-2021 the FFmpeg developers

built with gcc 8 (Debian 8.3.0-6)
configuration: --enable-debug --disable-optimizations
libavutil 57. 2.100 / 57. 2.100
libavcodec 59. 3.102 / 59. 3.102
libavformat 59. 4.101 / 59. 4.101
libavdevice 59. 0.100 / 59. 0.100
libavfilter 8. 0.103 / 8. 0.103
libswscale 6. 0.100 / 6. 0.100
libswresample 4. 0.100 / 4. 0.100

Segmentation fault

Here is the information from gdb:

r -i ../../vid1.mov
Starting program: /video/FFmpeg-n3.0.9/FFmpeg/ffmpeg_g -i ../../vid1.mov
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ffmpeg version N-103056-g4ff73add5d Copyright (c) 2000-2021 the FFmpeg developers

built with gcc 8 (Debian 8.3.0-6)
configuration: --enable-debug --disable-optimizations
libavutil 57. 2.100 / 57. 2.100
libavcodec 59. 3.102 / 59. 3.102
libavformat 59. 4.101 / 59. 4.101
libavdevice 59. 0.100 / 59. 0.100
libavfilter 8. 0.103 / 8. 0.103
libswscale 6. 0.100 / 6. 0.100
libswresample 4. 0.100 / 4. 0.100

Program received signal SIGSEGV, Segmentation fault.
0x0000561460e856c5 in get_bits (s=0x7ffde03b35e0, n=16) at ./libavcodec/get_bits.h:404
404 UPDATE_CACHE(re, s);
(gdb) bt
#0 0x0000561460e856c5 in get_bits (s=0x7ffde03b35e0, n=16) at ./libavcodec/get_bits.h:404
#1 0x0000561460e857c7 in get_bits_long (s=0x7ffde03b35e0, n=32) at ./libavcodec/get_bits.h:563
#2 0x0000561460e8f05c in mov_read_stsz (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:2888
#3 0x0000561460e9bb32 in mov_read_default (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:7030
#4 0x0000561460e9bb32 in mov_read_default (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:7030
#5 0x0000561460e9bb32 in mov_read_default (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:7030
#6 0x0000561460e9bb32 in mov_read_default (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:7030
#7 0x0000561460e9373c in mov_read_trak (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:4238
#8 0x0000561460e9bb32 in mov_read_default (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:7030
#9 0x0000561460e896bd in mov_read_moov (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:1163
#10 0x0000561460e9bb32 in mov_read_default (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:7030
#11 0x0000561460e9d5a8 in mov_read_header (s=0x5614645bd540) at libavformat/mov.c:7573
#12 0x0000561460f752c8 in avformat_open_input (ps=0x7ffde03b3ec0, filename=0x7ffde03b5a72 "../../vid1.mov", fmt=0x0, options=0x5614645bd428) at libavformat/utils.c:570
#13 0x00005614609ea877 in open_input_file (o=0x7ffde03b3fd0, filename=0x7ffde03b5a72 "../../vid1.mov") at fftools/ffmpeg_opt.c:1181
#14 0x00005614609f8bb4 in open_files (l=0x5614645bd058, inout=0x561461f0fad7 "input", open_file=0x5614609e9f3d <open_input_file>) at fftools/ffmpeg_opt.c:3344
#15 0x00005614609f8d24 in ffmpeg_parse_options (argc=3, argv=0x7ffde03b4668) at fftools/ffmpeg_opt.c:3384
#16 0x0000561460a1657b in main (argc=3, argv=0x7ffde03b4668) at fftools/ffmpeg.c:5011
(gdb) up
#1 0x0000561460e857c7 in get_bits_long (s=0x7ffde03b35e0, n=32) at ./libavcodec/get_bits.h:563
563 unsigned ret = get_bits(s, 16) << (n - 16);
(gdb)
#2 0x0000561460e8f05c in mov_read_stsz (c=0x5614645be1c0, pb=0x5614645c6240, atom=...) at libavformat/mov.c:2888
2888 sc->sample_sizes[i] = get_bits_long(&gb, field_size);
(gdb) list
2883 }
2884
2885 init_get_bits(&gb, buf, 8*num_bytes);
2886
2887 for (i = 0; i < entries && !pb->eof_reached; i++) {
2888 sc->sample_sizes[i] = get_bits_long(&gb, field_size);
2889 if (sc->sample_sizes[i] < 0) {
2890 av_free(buf);
2891 av_log(c->fc, AV_LOG_ERROR, "Invalid sample size %d\n", sc->sample_sizes[i]);
2892 return AVERROR_INVALIDDATA;
(gdb) p num_bytes
$1 = 358473600

According to the QuickTime spec, this is a valid sample size. But, init_get_bits has failed, and the return code isn’t checked so we get a segmentation fault a few lines later.

[Bruce]

ffmpeg output with -v 9 -loglevel 99

[Bruce]

ffmpeg log with -report flag

[mkver]

Can you test this patch?

[Bruce]

Replying to mkver:

Can you test this patch?

This patch fixes the crash:

./ffmpeg -i vid1.mov
ffmpeg version N-103056-g4ff73add5d Copyright (c) 2000-2021 the FFmpeg developers

built with Apple clang version 11.0.3 (clang-1103.0.32.62)
configuration: --enable-debug --disable-optimizations
libavutil 57. 2.100 / 57. 2.100
libavcodec 59. 3.102 / 59. 3.102
libavformat 59. 4.101 / 59. 4.101
libavdevice 59. 0.100 / 59. 0.100
libavfilter 8. 0.103 / 8. 0.103
libswscale 6. 0.100 / 6. 0.100
libswresample 4. 0.100 / 4. 0.100

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fe091c11680] error reading header
vid1.mov: Invalid data found when processing input

I wonder why the return code from the call to init_get_bits is not checked. Seems like some places in the code check it, but others do not. What is the rationale? Thanks!

Bruce

[Elon Musk]

Probably fixed with c2d853c1aae22bbc7d9905c43a9f16cb2ba3ba33