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 8524D45CDF for ; Fri, 2 Jun 2023 20:19:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D784868C364; Fri, 2 Jun 2023 23:19:52 +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 5C27C68BEC4 for ; Fri, 2 Jun 2023 23:19:46 +0300 (EEST) X-GND-Sasl: michael@niedermayer.cc Received: by mail.gandi.net (Postfix) with ESMTPSA id 8A7E51C0002 for ; Fri, 2 Jun 2023 20:19:45 +0000 (UTC) Date: Fri, 2 Jun 2023 22:19:44 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230602201944.GY1391451@pb2> References: <20230601222601.12631-1-michael@niedermayer.cc> <20230601222601.12631-2-michael@niedermayer.cc> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 2/3] avcodec/cbs_av1: Clear obu.metadata on error 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="===============7012472210673357644==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7012472210673357644== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jvmCgFKx2lledmPK" Content-Disposition: inline --jvmCgFKx2lledmPK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 02, 2023 at 02:28:24AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On error pointers can be left NULL while code later assumes these not t= o be NULL > >=20 > > Fixes: NULL pointer dereference > > Fixes: 59359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzz= er-6726080594313216 > >=20 > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz= /tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/cbs_av1.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > >=20 > > diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c > > index 8788fee099..7f3f4da2f5 100644 > > --- a/libavcodec/cbs_av1.c > > +++ b/libavcodec/cbs_av1.c > > @@ -1013,8 +1013,10 @@ static int cbs_av1_read_unit(CodedBitstreamConte= xt *ctx, > > case AV1_OBU_METADATA: > > { > > err =3D cbs_av1_read_metadata_obu(ctx, &gbc, &obu->obu.met= adata); > > - if (err < 0) > > + if (err < 0) { > > + memset(&obu->obu.metadata, 0, sizeof(obu->obu.metadata= )); > > return err; > > + } > > } > > break; > > case AV1_OBU_PADDING: >=20 > 1. Before 97f4263, the current_obu was reset (and the packet effectively > discarded) upon errors from ff_cbs_read_packet(); yet this is no longer > true and it seems that the contents of current_obu will be processed in > the next call to av1_receive_frame(). This change seems to have been > unintentional. > 2. The commit message is weird: You claim that it is bad that a pointer > is NULL; and then you go on and zero it again. It would be better to > claim that the metadata is in an inconsistent state. > 3. There is a possibility for inconsistency in cbs_av1_syntax_template, > namely if the allocation fails, metadata OBU nevertheless claims to have > a payload_size > 0; payload_size should only be set after the allocation > succeeded. But this does not seem to be the issue in this testcase. > Presumably there are not enough bits left for the itu_t_t35_country_code > or its extension? In this case, cbs_av1 did not even make an error. > 4. Your fix is dangerous: In case the code were changed so that an error > can happen after a successful allocation, your memset would lead to > leaks. (The most likely possibility is the addition of a new type of > metadata; another way would be for the code to be changed to avoid > reading the metadata twice by reallocating (and overallocating) the > buffer as needed.) posting a suboptimal fix, if one isnt sure what is the clean way to fix it is a great way to have someone else make a better fix. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle=20 --jvmCgFKx2lledmPK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZHpO4AAKCRBhHseHBAsP q+SVAKCcIZcWDr0meC26Gtzq7X6NCt9TtACdGEsr20fYQPDNBdQZjcpFiB4HxDc= =TF0e -----END PGP SIGNATURE----- --jvmCgFKx2lledmPK-- --===============7012472210673357644== 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". --===============7012472210673357644==--