On Sun, Aug 21, 2022 at 04:23:09PM +0200, Michael Niedermayer wrote:
> 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 ?

ping

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides