On Sun, Aug 21, 2022 at 12:54:57PM +0200, Paul B Mahol wrote: > On Fri, Aug 19, 2022 at 12:36 AM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > Fixes: out of array access > > Fixes: > > 50014/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4748914632294400 > > > > Alternatively the buffer size can be increased > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by > > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > > Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/speedhq.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c > > index c43de4f199..ffee5f973b 100644 > > --- a/libavcodec/speedhq.c > > +++ b/libavcodec/speedhq.c > > @@ -499,7 +499,7 @@ static int speedhq_decode_frame(AVCodecContext *avctx, > > AVFrame *frame, > > uint32_t second_field_offset; > > int ret; > > > > - if (buf_size < 4 || avctx->width < 8) > > + if (buf_size < 4 || avctx->width < 8 || avctx->width % 8 != 0) > > return AVERROR_INVALIDDATA; > > > > Is this right thing to do?
We can increase the buffer size or change how the %8 != 0 case is handled WIthout a non fuzzed file with such dimensions, I do not know what the correct handling of such a file is. What do you prefer to be done ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier
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".
