On Sun, May 31, 2020 at 10:58:16AM -0300, James Almer wrote:
> On 5/31/2020 10:50 AM, Michael Niedermayer wrote:
> > Fixes: NULL pointer dereference
> > Fixes: 
> > 22604/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5667739074297856.fuzz
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > ---
> >  libavformat/mlvdec.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
> > index dae13cae53..03aed71024 100644
> > --- a/libavformat/mlvdec.c
> > +++ b/libavformat/mlvdec.c
> > @@ -393,10 +393,14 @@ static int read_packet(AVFormatContext *avctx, 
> > AVPacket *pkt)
> >  {
> >      MlvContext *mlv = avctx->priv_data;
> >      AVIOContext *pb;
> > -    AVStream *st = avctx->streams[mlv->stream_index];
> > +    AVStream *st;
> >      int index, ret;
> >      unsigned int size, space;
> >  
> > +    if (!avctx->nb_streams)
> > +        return AVERROR_EOF;
> 
> Shouldn't you abort during read_header() instead if no streams are ever
> allocated?

read_header() should fail if the haeder is invalid.
is there something which says that "no streams" is invalid ?

As it is the read_header() code contains a if()  which only make
a difference for a "no stream" case. Which gave me the feeling that
it wasnt intended to fail in that case
but i can add the check for no streams in there where theres already
a check for that in read_header ...

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable

Attachment: signature.asc
Description: PGP signature

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

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

Reply via email to