[FFmpeg-trac] #1971(undetermined:new): Uninitialized memory reads in ff_h264_decode_nal
FFmpeg
trac at avcodec.org
Wed Nov 28 03:09:03 CET 2012
#1971: Uninitialized memory reads in ff_h264_decode_nal
--------------------------------------+----------------------------------
Reporter: ajschult | Type: defect
Status: new | Priority: normal
Component: undetermined | Version: 1.0
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
--------------------------------------+----------------------------------
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.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1971>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list