Uninitialized memory reads in ff_h264_decode_nal

[Andrew Schultz]

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 ​http://rheneas.eng.buffalo.edu/~andrew/fatkid.flv 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.

[Carl Eugen Hoyos]

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

[reimar]

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.