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 7C6A041000 for ; Sat, 12 Aug 2023 14:33:34 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0470D68C5B3; Sat, 12 Aug 2023 17:33:32 +0300 (EEST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 796D468C5B1 for ; Sat, 12 Aug 2023 17:33:25 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 71EE660002 for ; Sat, 12 Aug 2023 14:33:24 +0000 (UTC) Date: Sat, 12 Aug 2023 16:33:23 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230812143323.GJ7802@pb2> References: <20230809183407.29554-1-michael@niedermayer.cc> <20230809193030.GA7802@pb2> <20230810093402.GB7802@pb2> <20230810154601.GF7802@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/mv30: Check the input length before allocation 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="===============0951411548034257042==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0951411548034257042== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bL62sxVaCthiIrER" Content-Disposition: inline --bL62sxVaCthiIrER Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 10, 2023 at 05:58:24PM +0200, Paul B Mahol wrote: > On Thu, Aug 10, 2023 at 5:46=E2=80=AFPM Michael Niedermayer > wrote: >=20 > > On Thu, Aug 10, 2023 at 12:12:51PM +0200, Paul B Mahol wrote: > > > On Thu, Aug 10, 2023 at 11:34=E2=80=AFAM Michael Niedermayer < > > michael@niedermayer.cc> > > > wrote: > > > > > > > On Wed, Aug 09, 2023 at 11:20:43PM +0200, Paul B Mahol wrote: > > > > > On Wed, Aug 9, 2023 at 9:30=E2=80=AFPM Michael Niedermayer < > > > > michael@niedermayer.cc> > > > > > wrote: > > > > > > > > > > > Hi Paul > > > > > > > > > > > > On Wed, Aug 09, 2023 at 08:53:03PM +0200, Paul B Mahol wrote: > > > > > > > This is not correct, and please stop writing such patches. > > Thanks. > > > > > > > > > > > > If there is a problem in the bugfix, please explain what the > > problem > > > > is. > > > > > > If you do not like the specific fix, you can fix it differently > > too or > > > > > > tell me what you prefer. > > > > > > Simply saying "no" with no explanation repeatedly is rude > > > > > > > > > > > > > > > > Patch breaks valid files. > > > > > > > > Does the patch break files you create intentionally or files > > > > pre-existing ? > > > > The check can fail if 2 data segments overlap, one can craft > > > > a file with that. The previous patches are implemented differently > > > > and dont have that behavior, you rejected them too and at the time > > > > you did call them "hacky" and did not mention that they break anyth= ing > > > > and also ignored all further questions > > > > > > > > I just implemented this one differently as the other way was reject= ed > > > > by you with no comment > > > > > > > > Also please provide the files this breaks so the issue can be > > > > fixed > > > > > > > > > > > Why not same thing for AV1 codec? > > > Just reduce max resolutions for mv30 to 32x32 and be done. > > > > Limiting the resolution to max 32x32 would break real samples > > for example V-codecs/mv30.avi > > > > if you suggest to limit it only for the fuzzer, well, that would not > > fix the timeout outside the fuzzer. > > For some decoders limiting the resolution in the fuzzer is the only > > practical > > option. But for mv30 this timeout really occurs because the input is not > > checked/validated. > > >=20 > But mv30 bitstream is not so trivial and can not be checked that easily > with your patches. for decode_intra the loop reads from mgb look like this: for (int y =3D 0; y < avctx->height; y +=3D 16) { =2E.. for (int x =3D 0; x < avctx->width; x +=3D 16) { =2E.. for (int b =3D 0; b < 6; b++) { int mode =3D get_bits_le(&mgb, 2); =2E.. } } the only way to escape this loop is through error exit so 2*6* number of 16x16 blocks is read unconditionally and its read from a place that has s->mode_size * 8 bits alternatively get_bits_left() can be used for decode inter: there is this at the begin mask =3D *gb; skip_bits_long(gb, mask_size * 8); mgb =3D *gb; skip_bits_long(gb, s->mode_size * 8); so we have at minimum (mask_size + s->mode_size) * 8 bits It does seem reasonable to me to check the input to contain enough bits for what is consumed If it breaks some real files, i very much would like to know what these files are doing >=20 > Also whole fuzzing idea of your work is flawed. what do you mean by "whole fuzzing idea" ? thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. U= ser questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. --bL62sxVaCthiIrER Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZNeYLwAKCRBhHseHBAsP q7nKAJ9m3+omoPP5edT6SKFd1o+5b+ZQgACgjufREfMXvNFuenPo2FWdE82sh4E= =D9Wr -----END PGP SIGNATURE----- --bL62sxVaCthiIrER-- --===============0951411548034257042== 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". --===============0951411548034257042==--