[FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: Check count in mxf_read_strong_ref_array()

Tomas Härdin tjoppen at acc.umu.se
Sun Mar 20 15:05:41 EET 2022


lör 2022-03-19 klockan 23:50 +0100 skrev Michael Niedermayer:
> On Mon, Mar 14, 2022 at 08:19:51PM +0100, Tomas Härdin wrote:
> > sön 2022-03-13 klockan 00:52 +0100 skrev Michael Niedermayer:
> > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > ---
> > >  libavformat/mxfdec.c | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index b85c10bf19..d7cdd22c8a 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -932,7 +932,13 @@ static int
> > > mxf_read_cryptographic_context(void
> > > *arg, AVIOContext *pb, int tag, i
> > >  
> > >  static int mxf_read_strong_ref_array(AVIOContext *pb, UID
> > > **refs,
> > > int *count)
> > >  {
> > > -    *count = avio_rb32(pb);
> > > +    unsigned c = avio_rb32(pb);
> > 
> > not uint32_t?
> 
> we dont need an exact length variable here

Right, we don't support 16-bit machines

> 
> 
> > 
> > > +
> > > +    //avio_read() used int
> > > +    if (c > INT_MAX / sizeof(UID))
> > > +        return AVERROR_PATCHWELCOME;
> > > +    *count = c;
> > > +
> > 
> > This should already be caught by av_calloc(), no?
> 
> the API as in the documentation of av_calloc() does not gurantee
> this. 

Yes it does:

  The allocated memory will have size `size * nmemb` bytes.
  [...]
  `NULL` if the block cannot be allocated

> Its bad practice if we write code that depends on some implementation
> of some code in a diferent module/lib

If av_calloc() does not guarantee this then it is useless. It is used
precisely for this all over the place. Are you going to change every
use of av_calloc() in mxfdec in the same way?

/Tomas



More information about the ffmpeg-devel mailing list