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 6AAEF43069 for ; Thu, 13 Jan 2022 14:27:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E6D5368B7DB; Thu, 13 Jan 2022 16:27:09 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9547368AF73 for ; Thu, 13 Jan 2022 16:27:03 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id E3D9A24017C for ; Thu, 13 Jan 2022 15:27:02 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Od-5SbZRaFCZ for ; Thu, 13 Jan 2022 15:27:02 +0100 (CET) Received: from lain.red.khirnov.net (lain.red.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.red.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 1D8FE240179 for ; Thu, 13 Jan 2022 15:27:02 +0100 (CET) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id 6D7C916008E; Thu, 13 Jan 2022 15:27:01 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CAM7PR03MB66604CDE9378053544E611338F539=40AM7PR03MB?= =?utf-8?q?6660=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?= References: <20220111204610.14262-1-anton@khirnov.net> =?utf-8?q?=3CAM7PR03M?= =?utf-8?q?B66604CDE9378053544E611338F539=40AM7PR03MB6660=2Eeurprd03=2Eprod?= =?utf-8?q?=2Eoutlook=2Ecom=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Thu, 13 Jan 2022 15:27:01 +0100 Message-ID: <164208402130.23111.5697543505397164851@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 01/35] lavu/fifo: disallow overly large fifo sizes 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: Quoting Andreas Rheinhardt (2022-01-13 14:59:49) > Anton Khirnov: > > The API currently allows creating FIFOs up to > > - UINT_MAX: av_fifo_alloc(), av_fifo_realloc(), av_fifo_grow() > > - SIZE_MAX: av_fifo_alloc_array() > > However the usable limit is determined by > > - rndx/wndx being uint32_t > > - av_fifo_[size,space] returning int > > so no FIFO should be larger than the smallest of > > - INT_MAX > > - UINT32_MAX > > - SIZE_MAX > > (which should be INT_MAX an all commonly used platforms). > > Return an error on trying to allocate FIFOs larger than this limit. > > --- > > libavutil/fifo.c | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/libavutil/fifo.c b/libavutil/fifo.c > > index d741bdd395..f2f046b1f3 100644 > > --- a/libavutil/fifo.c > > +++ b/libavutil/fifo.c > > @@ -20,14 +20,23 @@ > > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > */ > > > > +#include > > + > > #include "avassert.h" > > #include "common.h" > > #include "fifo.h" > > > > +#define FIFO_SIZE_MAX FFMIN3((uint64_t)INT_MAX, (uint64_t)UINT32_MAX, (uint64_t)SIZE_MAX) > > Aren't these casts unnecessary? Possibly yes. I mainly added them so that FIFO_SIZE_MAX is always the same type, which might prevent surprises. I can drop the casts if you think they are never necessary. > And actually dangerous? (They add the implicit requirement that > INT_MAX and SIZE_MAX fit into an uint64_t.) I'll grant you _theoretically_ dangerous - I've never heard of a posix-compliant platform with sizeof(int) > 64. And in any case that macro should be gone with the old API (was going to include a patch scheduling its removal, but apparently forgot - will send it later). -- Anton Khirnov _______________________________________________ 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".