[FFmpeg-devel] [PATCH 1/2] avformat/vividas: Check packet size

Anton Khirnov anton at khirnov.net
Thu Sep 29 17:10:22 EEST 2022


Quoting Michael Niedermayer (2022-09-29 00:35:09)
> On Wed, Sep 28, 2022 at 05:16:05PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2022-09-22 20:08:51)
> > > Fixes: signed integer overflow: 119760682 - -2084600173 cannot be represented in type 'int'
> > > Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-6745781167587328
> > > 
> > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > ---
> > >  libavformat/vividas.c | 13 +++++++++++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> > > index e9954f73ed0..e8efe49a5c0 100644
> > > --- a/libavformat/vividas.c
> > > +++ b/libavformat/vividas.c
> > > @@ -683,6 +683,7 @@ static int viv_read_packet(AVFormatContext *s,
> > >  
> > >      if (viv->sb_entries[viv->current_sb_entry].flag == 0) {
> > >          uint64_t v_size = ffio_read_varlen(pb);
> > > +        int last, last_start;
> > >  
> > >          if (!viv->num_audio)
> > >              return AVERROR_INVALIDDATA;
> > > @@ -704,14 +705,22 @@ static int viv_read_packet(AVFormatContext *s,
> > >              start = ffio_read_varlen(pb);
> > >              pcm_bytes = ffio_read_varlen(pb);
> > >  
> > > -            if (i > 0 && start == 0)
> > > -                break;
> > > +            if (i > 0) {
> > > +                if (start == 0)
> > > +                    break;
> > > +                if (start < last || start - (unsigned)last > INT_MAX)
> > 
> > What is the second condition for?
> 
> start is signed int so are "copyies" of it
> "start < last" would allow a negative last with a large start
> the 2nd check handles that.
> the difference of consequtive values are stored as int later
> 
> The patch tried to leave the storage types and check for it.
> The types could be changed or some other checks could be used
> I was undecided on this patch a bit too. I picked this mainly
> to keep changes more minimal but maybe this was not the best
> choice

Checking that start >= 0 would fix this as well, wouldn't it? I don't
think it makes sense for it to be negative.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list