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 5B4B540CEC for ; Sat, 9 Apr 2022 18:56:15 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6ED4E68B300; Sat, 9 Apr 2022 21:56:13 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 973A768B253 for ; Sat, 9 Apr 2022 21:56:06 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 2C580E6801 for ; Sat, 9 Apr 2022 20:56:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P2F3noDOwQj for ; Sat, 9 Apr 2022 20:56:05 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 58CCDE598E for ; Sat, 9 Apr 2022 20:56:05 +0200 (CEST) Date: Sat, 9 Apr 2022 20:56:05 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <20220330105802.GO2829255@pb2> Message-ID: References: <20220329212459.23440-1-michael@niedermayer.cc> <62c40964-d827-d044-cec3-233bfc04aaf1@gmail.com> <20220330105802.GO2829255@pb2> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/pcm_rechunk_bsf: unref packet before putting a new one in 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, 30 Mar 2022, Michael Niedermayer wrote: > On Tue, Mar 29, 2022 at 06:33:06PM -0300, James Almer wrote: >> On 3/29/2022 6:24 PM, Michael Niedermayer wrote: >>> Fixes: memleak >>> Fixes: 45982/clusterfuzz-testcase-minimized-ffmpeg_BSF_PCM_RECHUNK_fuzzer-5562089618407424 >>> >>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >>> Signed-off-by: Michael Niedermayer >>> --- >>> libavcodec/pcm_rechunk_bsf.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/libavcodec/pcm_rechunk_bsf.c b/libavcodec/pcm_rechunk_bsf.c >>> index 108d9e90b9..3f43934fe9 100644 >>> --- a/libavcodec/pcm_rechunk_bsf.c >>> +++ b/libavcodec/pcm_rechunk_bsf.c >>> @@ -153,6 +153,7 @@ static int rechunk_filter(AVBSFContext *ctx, AVPacket *pkt) >>> } >>> } >>> + av_packet_unref(s->in_pkt); >> >> This looks to me like it revealed a bug in the code above, which is meant to >> ensure s->in_pkt will be blank at this point. It should be fixed there >> instead. > > IIRC the problem was a input packet with size 0 > the code seems to assume 0 meaning no packet Is that valid here? The docs says that the encoders can generate 0 sized packets if there is side data in them. However - the PCM rechunk BSF using PCM packets - I am not sure this is intentional here. So overall it looks to me that the PCM rechunk BSF should reject 0 sized packets with AVERROR_INVALIDDATA, and the encoder or demuxer which produces the 0 sized packets should be fixed. Regards, Marton > > I can check more explicitly for that after ff_bsf_get_packet_ref() > and unref there, its more code through > > thx > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Its not that you shouldnt use gotos but rather that you should write > readable code and code with gotos often but not always is less readable > _______________________________________________ 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".