On Mon, Nov 16, 2020 at 01:05:07AM +0100, Michael Niedermayer wrote:
> On Sat, Nov 14, 2020 at 11:12:15AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2020-11-10 00:04:54)
> > > Fixes: OOM
> > > Fixes: 
> > > 26934/clusterfuzz-testcase-minimized-ffmpeg_dem_W64_fuzzer-5996784213819392
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > > ---
> > >  libavformat/wavdec.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> > > index a81f2c7a67..6e5f4ccc12 100644
> > > --- a/libavformat/wavdec.c
> > > +++ b/libavformat/wavdec.c
> > > @@ -920,7 +920,7 @@ static int w64_read_header(AVFormatContext *s)
> > >                  if (chunk_size == UINT32_MAX || (filesize >= 0 && 
> > > chunk_size > filesize))
> > >                      return AVERROR_INVALIDDATA;
> > >  
> > > -                value = av_mallocz(chunk_size + 1);
> > > +                value = av_malloc(chunk_size + 1);
> > 
> > This looks highly suspicious as a fix for anything other than
> > performance.
> 
> if iam not mistaken:
> The allocation doesnzt trigger OOM as no physical memory is allocated
> but once it is written to "z" it does and then OOMs
> if OTOH its written too while data is read from somewhere then a
> EOF ends writing and no OOM would happen

will apply 

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope

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