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 7F49149500 for ; Fri, 12 Apr 2024 16:52:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 433B668D28F; Fri, 12 Apr 2024 19:52:10 +0300 (EEST) Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A5EA368D23E for ; Fri, 12 Apr 2024 19:52:03 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:Content-Type:MIME-Version: Message-ID; bh=1oPVYPaB7GDwi1RUab1LK5gU6f5dI0fA8BMYhAKOtYQ=; b=i a8gxUfs/Inw6hb2roE20LNZvyWA0Xnsg9oAmrOjkYwfMlbv8gzbnMKtK212F1ZCD Yt26VmLczF65GpSvwfhCTRnP56eShrjGpNy+n5PL+NC3cxxUrLgg0fxW0d/u9Bsp bOj2w9cTf0+ePtAPeFz6NvfUcUTvP3HawBlPdGAhk0= Received: from lumingyindetect$163.com ( [106.39.130.76] ) by ajax-webmail-wmsvr-40-122 (Coremail) ; Sat, 13 Apr 2024 00:51:54 +0800 (CST) X-Originating-IP: [106.39.130.76] Date: Sat, 13 Apr 2024 00:51:54 +0800 (CST) From: lumingyindetect To: "FFmpeg development discussions and patches" X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT5.0.14 build 20230109(dcb5de15) Copyright (c) 2002-2024 www.mailtech.cn 163com In-Reply-To: <405113c3-a170-4a69-9b20-3a98292f6b60@gmail.com> References: <20240412130935.1368867-1-lumingyindetect@163.com> <405113c3-a170-4a69-9b20-3a98292f6b60@gmail.com> X-NTES-SC: AL_Qu2aAPWfv08q4iSaYukfm0gUjuY7Uca3s/Qh2IdWO514jDHp/CQjfmJiJWTI+tmCFgyQuTm2QAFj0+BRbJtecLk2jOCyoJIjEzC/9KoVbsTYXQ== MIME-Version: 1.0 Message-ID: <634b5ace.f16c.18ed33909c1.Coremail.lumingyindetect@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: _____wD33xWqZhlmqXoNAA--.39178W X-CM-SenderInfo: poxpx0hj1l0vphwhu3i6rwjhhfrp/1tbiKQq+92VOCczhXQAAs4 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_mux_init: fix a memory leak in ffmpeg_mux_init.c 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Thank you for your patient response! I have submitted the new patch as requested. The link is https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240412164441.1727089-1-lumingyindetect@163.com/ At 2024-04-12 21:41:25, "James Almer" wrote: >On 4/12/2024 10:09 AM, LuMingYin wrote: >> In the file ffmpeg_mux_init.c located at /FFmpeg/fftools/, a pointer variable named pts is defined at line 2830. At line 2836, this pointer is allocated a dynamic memory area using the function av_malloc_array. When the if statement at line 2852 evaluates to true, there are two possible scenarios. The first scenario is when nb_ch > INT_MAX - size. In this case, the program should release the dynamic memory area pointed to by pts before returning. The second scenario is when the realloc operation for the pts pointer fails. In this case, since the av_realloc_f function releases the original memory in case of reallocation failure, there is no need to release the memory area pointed to by pts. Because the handling of these two scenarios differs, to fix the memory leak issue caused by the first scenario, my patch separates the treatment of these cases. >> >> Signed-off-by: LuMingYin >> --- >> fftools/ffmpeg_mux_init.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c >> index 6d8bd5bcdf..1f27e4e4f4 100644 >> --- a/fftools/ffmpeg_mux_init.c >> +++ b/fftools/ffmpeg_mux_init.c >> @@ -2849,8 +2849,12 @@ static int parse_forced_key_frames(void *log, KeyframeForceCtx *kf, >> unsigned int nb_ch = mux->fc->nb_chapters; >> int j; >> >> - if (nb_ch > INT_MAX - size || >> - !(pts = av_realloc_f(pts, size += nb_ch - 1, >> + if (nb_ch > INT_MAX - size) { >> + av_freep(&pts); >> + return AVERROR(ENOMEM); > >There's a fail label at the end that frees pts. You should set ret to >AVERROR(ENOMEM) and goto it. > >An alternative could be something like > >> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c >> index 1d0a210450..0d93f0eff2 100644 >> --- a/fftools/ffmpeg_mux_init.c >> +++ b/fftools/ffmpeg_mux_init.c >> @@ -2959,10 +2959,11 @@ static int parse_forced_key_frames(void *log, KeyframeForceCtx *kf, >> unsigned int nb_ch = mux->fc->nb_chapters; >> int j; >> >> - if (nb_ch > INT_MAX - size || >> - !(pts = av_realloc_f(pts, size += nb_ch - 1, >> - sizeof(*pts)))) >> - return AVERROR(ENOMEM); >> + if (nb_ch > (INT_MAX - size) / sizeof(*pts) || >> + av_reallocp(&pts, (size += nb_ch - 1) * sizeof(*pts))) { >> + ret = AVERROR(ENOMEM); >> + goto fail; >> + } >> >> if (p[8]) { >> ret = av_parse_time(&t, p + 8, 1); > >Where av_reallocp() will set pts to NULL after freeing, so the free in >the fail label will be a no-op, and we always jump to fail on failure in >case it's extended to do further cleaning. >_______________________________________________ >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". _______________________________________________ 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".