Opened 7 years ago

Closed 7 years ago

#1971 closed defect (invalid)

Uninitialized memory reads in ff_h264_decode_nal

Reported by: ajschult Owned by:
Priority: normal Component: undetermined
Version: 1.0 Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


ff_h264_decode_nal makes decisions based on uninitialized memory

How to reproduce:

% valgrind avidemux3_qt4 h264_decode_nal.flv

I can only reproduce this with avidemux, but (from code inspection) avidemux is behaving well and this is an ffmpeg bug.

loading in avidemux under valgrind, valgrind reports two uninitialized memory reads.

I see ff_h264_decode_nal (in h264.c) get called three times. The second time with length=4. Nonetheless, with HAVE_FAST_64BIT, it will try to read 8 bytes (UMR 1) via the macro AV_RN64A. Furthermore, the FIND_FIRST_ZERO macro happily walks off the end of src (UMR 2) because all of the bytes are non-zero. It's like it's not even trying to stay in the bounds of the array.

In the end, the effects of this are minimal since the whole point of the loop was to set length, and once it steps past the end, length won't be altered. However, in other situations this could cause a segfault for reading memory it was not allowed to read.

The 4 bytes that ff_h264_decode_nal is supposed to look at are initialized and (following the buffer up the call stack to ff_h264_decode_extradata), the larger buffer of extradata is also all initialized.

Change History (3)

comment:1 Changed 7 years ago by cehoyos

Please test with ffmpeg (the application), and in any case, please add valgrind output.

comment:2 Changed 7 years ago by cehoyos

  • Keywords h264 added

comment:3 Changed 7 years ago by reimar

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

All input to FFmpeg is required to be padded with FF_INPUT_BUFFER_PADDING_SIZE zeros.
According to your description this is not the case, which makes this a bug in avidemux.

Note: See TracTickets for help on using tickets.