From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 3ED594594D for ; Tue, 28 Mar 2023 20:11:08 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EF4E568CB25; Tue, 28 Mar 2023 23:11:04 +0300 (EEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1741668C31D for ; Tue, 28 Mar 2023 23:10:59 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 62CF71C0003 for ; Tue, 28 Mar 2023 20:10:56 +0000 (UTC) Date: Tue, 28 Mar 2023 22:10:55 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230328201055.GB375355@pb2> References: <20230326222642.2489-1-michael@niedermayer.cc> <20230326222642.2489-4-michael@niedermayer.cc> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 4/4] avcodec/vp3: Check width to avoid assertion failure X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============7406243604491344592==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7406243604491344592== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JyUo+2rKuw1VKSUr" Content-Disposition: inline --JyUo+2rKuw1VKSUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2023 at 01:45:01AM +0100, Kieran Kunhya wrote: > On Sun, 26 Mar 2023, 23:27 Michael Niedermayer, > wrote: >=20 > > Fixes: Assertion failure on x86-32 > > Fixes: > > 39641/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5= 925660741206016 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by > > : > > Michael Niedermayer > > --- > > libavcodec/vp3.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c > > index 9660def675f..22348559461 100644 > > --- a/libavcodec/vp3.c > > +++ b/libavcodec/vp3.c > > @@ -2353,6 +2353,8 @@ static av_cold int vp3_decode_init(AVCodecContext > > *avctx) > > s->avctx =3D avctx; > > s->width =3D FFALIGN(avctx->coded_width, 16); > > s->height =3D FFALIGN(avctx->coded_height, 16); > > + if (s->width < 18) > > + return AVERROR_PATCHWELCOME; > > if (avctx->codec_id !=3D AV_CODEC_ID_THEORA) > > avctx->pix_fmt =3D AV_PIX_FMT_YUV420P; > > avctx->chroma_sample_location =3D AVCHROMA_LOC_CENTER; > > @@ -2919,7 +2921,9 @@ static int theora_decode_header(AVCodecContext > > *avctx, GetBitContext *gb) > > /* sanity check */ > > if (av_image_check_size(visible_width, visible_height, 0, avctx) <= 0 > > || > > visible_width + offset_x > s->width || > > - visible_height + offset_y > s->height) { > > + visible_height + offset_y > s->height || > > + visible_width < 18 > > + ) { > > av_log(avctx, AV_LOG_ERROR, > > "Invalid frame dimensions - w:%d h:%d x:%d y:%d > > (%dx%d).\n", > > visible_width, visible_height, offset_x, offset_y, > > @@ -2965,6 +2969,8 @@ static int theora_decode_header(AVCodecContext > > *avctx, GetBitContext *gb) > > } else > > avctx->pix_fmt =3D AV_PIX_FMT_YUV420P; > > > > + if (s->width < 18) > > + return AVERROR_PATCHWELCOME; > > ret =3D ff_set_dimensions(avctx, s->width, s->height); > > if (ret < 0) > > return ret; > > -- > > 2.17.1 > > >=20 > Please provide some explanation around the number "18" Its because the source needed for MC of a block is 9x9 and chroma is 1/2 so a width of 18 is ok but 16 could result in a 8 linesize into which a 9x9 block would not fit. This is x86-32 specific probably as the linesize is rouded up more on 64bit If theres some value in such small sizes i could look into adjusting the linesize up in these cases? ill add this to the commit message: Fixes: Assertion failure on x86-32 av_assert2(block_w * sizeof(pixel) <=3D FFABS(buf_linesize)); in ff_= emulated_edge_mc() [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact --JyUo+2rKuw1VKSUr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZCNJygAKCRBhHseHBAsP q1oNAJsH9X1uNBnQgSgBlQWrryFZSgwEfwCgjTmzDWSMM36wg/Vl9/mOUAktB8c= =4Ubp -----END PGP SIGNATURE----- --JyUo+2rKuw1VKSUr-- --===============7406243604491344592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============7406243604491344592==--