Michael Niedermayer: > Fixes: division by zero > Fixes: > 43347/clusterfuzz-testcase-minimized-ffmpeg_dem_V210X_fuzzer-5846911637127168 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavformat/rawvideodec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/rawvideodec.c b/libavformat/rawvideodec.c > index 68547fc50ff..7581ba2c7d2 100644 > --- a/libavformat/rawvideodec.c > +++ b/libavformat/rawvideodec.c > @@ -100,6 +100,8 @@ static int rawvideo_read_header(AVFormatContext *ctx) > if (packet_size < 0) > return packet_size; > } > + if (packet_size == 0) > + return AVERROR_INVALIDDATA; > > st->codecpar->format = pix_fmt; > ctx->packet_size = packet_size; >
1. I agree with Lance that AVERROR(EINVAL) is the proper error code; after all, the dimensions are based upon options and not read from the input. 2. The dimensions were checked by av_image_check_size() before 41f213c3bf629d549400e935e7f123e6cfa959ab. 3. The same can happen with bitpacked. Your check should also catch this. 4. But I don't see anything that actually ensures that the multiplications do not overflow. - Andreas _______________________________________________ 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".
