On 21.06.2019, at 00:47, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type > 'int' > Fixes: > 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavcodec/alsdec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c > index 79d22b7c2b..8e0d3e5f83 100644 > --- a/libavcodec/alsdec.c > +++ b/libavcodec/alsdec.c > @@ -1990,6 +1990,8 @@ static av_cold int decode_init(AVCodecContext *avctx) > > // allocate quantized parcor coefficient buffer > num_buffers = sconf->mc_coding ? avctx->channels : 1; > + if (num_buffers * (uint64_t)num_buffers > INT_MAX) > + return AVERROR_INVALIDDATA; It would be nice if it was clear which code this check protects, i.e. some connection between the check and the code that overflows. I guess one might also ask if > 30 000 channels might not be something to catch and disallow earlier and generally... _______________________________________________ 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".
