Re: [FFmpeg-devel] [PATCH 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

[Marton Balint <cus@passwd.hu>]

On Wed, 21 Sep 2022, Tomas Härdin wrote:

> ons 2022-09-21 klockan 11:35 +0200 skrev Michael Niedermayer:
>> On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
>> > tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
>> > > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
>> > > > Fixes: signed integer overflow: 9223372036854775807 - -
>> > > > 2146905566
>> > > > cannot be represented in type 'long'
>> > > > Fixes: 50993/clusterfuzz-testcase-minimized-
>> > > > ffmpeg_dem_MXF_fuzzer-
>> > > > 6570996594769920
>> > > > 
>> > > > Found-by: continuous fuzzing process 
>> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>> > > > ---
>> > > >  libavformat/mxfdec.c | 6 +++++-
>> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
>> > > > 
>> > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>> > > > index e63e803aa56..da81fea3bc1 100644
>> > > > --- a/libavformat/mxfdec.c
>> > > > +++ b/libavformat/mxfdec.c
>> > > > @@ -3681,6 +3681,7 @@ static int
>> > > > mxf_read_header(AVFormatContext
>> > > > *s)
>> > > >      KLVPacket klv;
>> > > >      int64_t essence_offset = 0;
>> > > >      int ret;
>> > > > +    int64_t run_in;
>> > > >  
>> > > >      mxf->last_forward_tell = INT64_MAX;
>> > > >  
>> > > > @@ -3690,7 +3691,10 @@ static int
>> > > > mxf_read_header(AVFormatContext
>> > > > *s)
>> > > >      }
>> > > >      avio_seek(s->pb, -14, SEEK_CUR);
>> > > >      mxf->fc = s;
>> > > > -    mxf->run_in = avio_tell(s->pb);
>> > > > +    run_in = avio_tell(s->pb);
>> > > > +    if (run_in < 0 || run_in != (int)run_in)
>> > > 
>> > > run_in > INT_MAX is more clear
>> > > 
>> > > It strikes me that run_in is also used in lots of places in the
>> > > demuxer
>> > > without checking for overflow
>> > 
>> > I went and checked S377m and the run-in sequence "shall be less
>> > than
>> > 65536 bytes long". Both the 2004 and 2009 version of the spec agree
>> > on
>> > this. So we should reject run_in >= 65536, and mxf_probe() should
>> > be
>> > similarly adjusted.
>> 
>> ok, will do
>> 
>> thx for checking
>> 
>> i will change the patch by:
>> @@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
>>      avio_seek(s->pb, -14, SEEK_CUR);
>
> Oh and also the call to mxf_read_sync() could be supplied with a
> maximum number of bytes to read, allowing the code to bail out faster

Yeah, I wanted to suggest this as well. And please allow 65536-byte 
run-in, even if that is not strictly allowed by the current standard, 
because the MXF book has no problem with that:

(run-in is) "...a sequence of up to 65536 bytes at the front of the file 
that precedes the first partition pack..."

Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".