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 074E740417 for ; Mon, 20 Dec 2021 20:51:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C601168AEE9; Mon, 20 Dec 2021 22:51:10 +0200 (EET) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 45D4868A609 for ; Mon, 20 Dec 2021 22:51:04 +0200 (EET) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4JHsF33jrqzQjwk for ; Mon, 20 Dec 2021 21:51:03 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Message-ID: Date: Tue, 21 Dec 2021 02:20:48 +0530 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20211220204609.199-1-ffmpeg@gyani.pro> From: Gyan Doshi In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/mov: abort reading truncated stts 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 2021-12-21 02:18 am, Andreas Rheinhardt wrote: > Gyan Doshi: >> Avoids overreading the box and ingesting absurd values into stts_data >> --- >> libavformat/mov.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/libavformat/mov.c b/libavformat/mov.c >> index 2aed6e80ef..5a7209837f 100644 >> --- a/libavformat/mov.c >> +++ b/libavformat/mov.c >> @@ -2935,6 +2935,11 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom) >> avio_rb24(pb); /* flags */ >> entries = avio_rb32(pb); >> >> + if (atom.size < 8 + (int64_t)entries*8) { >> + av_log(c->fc, AV_LOG_ERROR, "Truncated STTS box for st %d.\n", c->fc->nb_streams-1); >> + return AVERROR_INVALIDDATA; >> + } >> + >> av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n", >> c->fc->nb_streams-1, entries); >> >> > This might fix the issue with the fuzzer sample Michael gave you, but > what would stop the fuzzer (or a malicious adversary) from simply using > a gigantic atom size? Do you want the comparison to switch to a strict inequality? Regards, Gyan _______________________________________________ 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".