Re: [FFmpeg-devel] [PATCH 1/6] avcodec/utils: allocate a line more for VC1 and WMV3

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/6] avcodec/utils: allocate a line more for VC1 and WMV3
Date: Thu, 12 Jan 2023 15:43:15 +0100
Message-ID: <20230112144315.GK1949656@pb2> (raw)
In-Reply-To: <AS8P250MB07440FD9F6FFF27AE06C4B698FFD9@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>

[-- Attachment #1.1: Type: text/plain, Size: 1976 bytes --]

On Thu, Jan 12, 2023 at 08:38:08AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: out of array read on 32bit
> > Fixes: 54857/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5840588224462848
> > 
> > The chroma MC code reads over the currently allocated frame.
> > Alternative fixes would be allocating a few bytes more at the end instead of a whole
> > line extra or to adjust the threshold where the edge emu code is activated
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavcodec/utils.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > index 2b63a498b9..1aa0a05a31 100644
> > --- a/libavcodec/utils.c
> > +++ b/libavcodec/utils.c
> > @@ -321,6 +321,7 @@ void avcodec_align_dimensions2(AVCodecContext *s, int *width, int *height,
> >      *width  = FFALIGN(*width, w_align);
> >      *height = FFALIGN(*height, h_align);
> >      if (s->codec_id == AV_CODEC_ID_H264 || s->lowres ||
> > +        s->codec_id == AV_CODEC_ID_VC1  || s->codec_id == AV_CODEC_ID_WMV3 ||
> >          s->codec_id == AV_CODEC_ID_VP5  || s->codec_id == AV_CODEC_ID_VP6 ||
> >          s->codec_id == AV_CODEC_ID_VP6F || s->codec_id == AV_CODEC_ID_VP6A
> >      ) {
> 
> Does this only happen on 32bit systems? If so, why?

Id have to double check, some of the issues in this set where 32bit specific some not
But the x86 codepath has special cases i think for non interpolated cases while
the C path which was used in the issue does not.
A check could also be added to the C path to not read the next line whan not needed
the patch is just folllowing what h264 does 

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".