On Sun, Nov 08, 2020 at 03:42:30AM +0100, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Fixes: signed integer overflow: -2147483648 - 4 cannot be represented in > > type 'int' > > Fixes: > > 26907/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5746202330267648 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/cfhd.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c > > index a2b9c7c76a..e3fbfa4b91 100644 > > --- a/libavcodec/cfhd.c > > +++ b/libavcodec/cfhd.c > > @@ -617,6 +617,10 @@ static int cfhd_decode(AVCodecContext *avctx, void > > *data, int *got_frame, > > s->peak.level = 0; > > } else if (tag == -PeakLevel && s->peak.offset) { > > s->peak.level = data; > > + if (s->peak.offset < INT_MIN + 4) { > > + ret = AVERROR_INVALIDDATA; > > + goto end; > > + } > > bytestream2_seek(&s->peak.base, s->peak.offset - 4, SEEK_CUR); > > } else > > av_log(avctx, AV_LOG_DEBUG, "Unknown tag %i data %x\n", tag, > > data); > > > Is this peak.offset actually intended to be signed?
it is signed in the reference code ive seen > And if so wouldn't > it make more sense to actually check that the buffer contains the seek > target? the reference code does not check that but i agree it of course makes sense. posted a patch which should do that thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban
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".
