On Fri, Feb 04, 2022 at 04:29:18AM +0100, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Fixes: Infinite loop > > Fixes: > > 43932/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6175167573786624 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavformat/matroskadec.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > > index d165f6ab90..5a9acfb247 100644 > > --- a/libavformat/matroskadec.c > > +++ b/libavformat/matroskadec.c > > @@ -1742,7 +1742,7 @@ static int matroska_decode_buffer(uint8_t **buf, int > > *buf_size, > > case MATROSKA_TRACK_ENCODING_COMP_BZLIB: > > { > > bz_stream bzstream = { 0 }; > > - if (BZ2_bzDecompressInit(&bzstream, 0, 0) != BZ_OK) > > + if (!pkt_size || BZ2_bzDecompressInit(&bzstream, 0, 0) != BZ_OK) > > return -1; > > bzstream.next_in = data; > > bzstream.avail_in = isize; > > I see nothing in the zlib-API manual that would preclude this from > happening with zlib, too, so it should be checked there, too. > LGTM apart from that.
It didnt happen with the same case when i just routed it to the zlib instead of bz case. But i didnt look what happened exactly [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up.
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".
