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 <michael@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 <michael@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