[Ffmpeg-devel] fuzzer bugs

[Måns Rullgård]

Diego Biurrun said:
> On Thu, Jan 25, 2007 at 02:07:22PM +0100, Diego Biurrun wrote:
>> On Tue, Jan 16, 2007 at 11:07:46AM +0100, Jindrich Makovicka wrote:
>> > On 1/15/07, Diego Biurrun <diego at biurrun.de> wrote:
>> > >
>> > >Samuel Hocevar wrote his own fuzzer and let it loose on some multimedia
>> > >players:
>> > >
>> > >http://sam.zoy.org/zzuf/
>> > >
>> > >ffplay shows quite a few crashes, MPlayer as well, some of which are
>> > >related to FFmpeg.  No time for details right now, but it's easy enough
>> > >to reproduce and the samples are tiny.
>> >
>> > MPlayer's mpeg1 sample (http://sam.zoy.org/zzuf/lol-mplayer.mpg) may
>> > actually expose a bug in ffmpeg h264 decoder:
>> >
>> > [h264 @ 0x869b678]insane cropping not completely supported, this could
>> > look slightly wrong ...
>> > [h264 @ 0x869b678]Unknown NAL code: 15
>> > [h264 @ 0x869b678]Unknown NAL code: 16
>> > [h264 @ 0x869b678]Unknown NAL code: 0
>> > [h264 @ 0x869b678]slice type too large (0) at 0 0
>> > [h264 @ 0x869b678]decode_slice_header error
>> > [h264 @ 0x869b678]non existing PPS referenced
>> > [h264 @ 0x869b678]decode_slice_header error
>> > ==7924== Jump to the invalid address stated on the next line
>> > ==7924==    at 0x0: ???
>> > ==7924==    by 0x83FF46C: decode_slice (h264.c:7372)
>> > ==7924==    by 0x84001C4: decode_nal_units (h264.c:8075)
>> > ==7924==    by 0x840125C: decode_frame (h264.c:8218)
>> > ==7924==    by 0x82474BF: avcodec_decode_video (utils.c:904)
>> > ==7924==    by 0x812BA92: decode (vd_ffmpeg.c:774)
>> > ==7924==    by 0x80F3235: decode_video (dec_video.c:355)
>> > ==7924==    by 0x8098620: main (mplayer.c:3440)
>> > ==7924==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
>>
>> For the record: This seems to have been fixed by recent h264.c changes,
>> but now there is an infinite loop (or so it seems) with the following
>> output:
>>
>> [h264 @ 0x10719f54]warning: first frame is no keyframe
>
> The problem goes away if I use the libavformat demuxer, so the problem
> is not in FFmpeg.

Yes and no.  From the stack trace it is apparent that the H.264 decoder does
something bad when given certain input data.  Your test only shows that the
demuxers are passing different data to the decoder.  This is perfectly fine,
since there are no rules governing the handling of invalid input.

-- 
M?ns Rullg?rd
mru at inprovide.com