Michael Niedermayer: > Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented > in type 'long' > Fixes: Timeout > Fixes: > 26434/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5752845451919360 > Fixes: > 26444/clusterfuzz-testcase-minimized-ffmpeg_dem_BINK_fuzzer-4697773380993024 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavformat/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index e8335a601f..59d65a8092 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -253,7 +253,7 @@ int ffio_limit(AVIOContext *s, int size) > remaining= FFMAX(remaining, 0); > } > > - if (s->maxsize>= 0 && remaining+1 < size) { > + if (s->maxsize>= 0 && remaining < size - (int64_t)1) { > av_log(NULL, remaining ? AV_LOG_ERROR : AV_LOG_DEBUG, > "Truncating packet of size %d to %"PRId64"\n", size, remaining+1); > size = remaining+1; > } > The +1 here seems very weird. If remaining + 1 == size, the packet will not be truncated, despite there not being enough data left.
The only reason for its existence I can think of is that it is designed to counter the potential -1 from s->maxsize = newsize - !newsize a few lines above. Yet this makes no sense: If newsize == 0, s->maxsize has just been set to -1 (indicating that future calls to ffio_limit() should not try again to get the filesize) and the second check above will not be reached at all. So how about just removing the +1 in all three lines above? - Andreas PS: And while just at it: You can also add a space to "s->maxsize>= 0". _______________________________________________ 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".
