From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 07 Sep 2026 10:21:32 +0200 Received: from mx1.white.stw.pengutronix.de ([2a0a:edc0:0:b01:1d::107]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x3Ubb-001394-2u for lore@lore.pengutronix.de; Mon, 07 Sep 2026 10:21:32 +0200 Authentication-Results: mx1.white.stw.pengutronix.de; dkim=pass header.d=lists.infradead.org header.s=bombadil.20210309 header.b=yVI4NllR; spf=pass (mx1.white.stw.pengutronix.de: domain of "barebox-bounces+lore=pengutronix.de@lists.infradead.org" designates 2607:7c80:54:3::133 as permitted sender) smtp.mailfrom="barebox-bounces+lore=pengutronix.de@lists.infradead.org"; dmarc=none Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by mx1.white.stw.pengutronix.de (Postfix) with ESMTPS id 7CBB82018A0 for ; Mon, 07 Sep 2026 10:21:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OD6ilriFPJ+XmTYTa/CIzeJWVhXys7+z/yLMy5lZALY=; b=yVI4NllRZexHAu+xi0XRfsmhtt W+g7snJriI6M6+KUHzlujTvP6whHm76GE588kj7nfX0PMoyyOlRTnpWamuub5yd+6LbRVHU8W6QI6 XYYfigk4PxGqVIuqDkG+F6v8qkIjKSzcIYF7iBI29bo9krGTibKLV9q2hf16iTVi/TCh/Z0SIEDfk hMiSvMLrxWU21wlxM+VKMZG+bq8NHsAOceZ3w9+nIJqdPNPR21HHBIqg3DtaQzC7gZd7jfAlR1FEn jvR39pqbE1PjdOcQwTkbz/GYElbHulSeoz2uzPiimcuDw3yqE1MPSZ1F2GBu7RyE0jLfVpr1r7QC9 WRXldhUg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3UaD-00000006FeY-0FOg; Mon, 07 Sep 2026 08:20:05 +0000 Received: from mx1.white.stw.pengutronix.de ([2a0a:edc0:0:b01:1d::107]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3Ua8-00000006FcW-3cjP for barebox@lists.infradead.org; Mon, 07 Sep 2026 08:20:03 +0000 Received: from [0.0.0.0] (ptz.office.stw.pengutronix.de [IPv6:2a0a:edc0:0:900:1d::77]) (Authenticated sender: afa@pengutronix.de) by mx1.white.stw.pengutronix.de (Postfix) with ESMTPSA id 96BAD200FED; Mon, 07 Sep 2026 10:19:55 +0200 (CEST) Message-ID: <9af0c47b-0648-4626-b32c-ef2df3669102@pengutronix.de> Date: Mon, 7 Sep 2026 10:19:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] fs: reject inodes whose size the superblock cannot address To: Sascha Hauer Cc: Barebox List , Stefan Kerkmann References: <20260904091551.3713729-1-s.hauer@pengutronix.de> <94032e43-342e-4bff-86d8-8294242760c1@pengutronix.de> From: Ahmad Fatoum Content-Language: en-US, de-DE, de-BE In-Reply-To: <94032e43-342e-4bff-86d8-8294242760c1@pengutronix.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260907_012001_077814_DAD268AC X-CRM114-Status: GOOD ( 18.77 ) X-Spam-Score: -1.9 (-) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello Sascha, On 9/4/26 1:13 PM, Sascha Hauer wrote: > On 2026-09-04 13:05, Ahmad Fatoum wrote: >> >> >> On 9/4/26 11:15 AM, Sascha Hauer wrote: >>> f_size is an alias for the inode's i_size, and filesystems read t [...] Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 DMARC_MISSING Missing DMARC policy X-BeenThere: barebox@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "barebox" X-Rspamd-Server: mx1 X-Stat-Signature: rs6ggxpff7ydx4ig4d4pa8ktwnn8gx8d X-Rspamd-Queue-Id: 7CBB82018A0 X-Spamd-Result: default: False [-57.61 / 15.00]; RECEIVED_AUTHENTICATED_BY_MX1(-50.00)[]; BAYES_HAM(-3.00)[100.00%]; DWL_DNSWL_MED(-2.00)[infradead.org:dkim]; KNOWN_LIST_ID(-1.00)[barebox.lists.infradead.org]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.40)[2607:7c80:54:3::133:from,2a0a:edc0:0:900:1d::77:received]; R_SPF_ALLOW(-0.20)[+mx:c]; MAILLIST(-0.20)[mailman]; R_DKIM_ALLOW(-0.20)[lists.infradead.org:s=bombadil.20210309]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; RCVD_COUNT_THREE(0.00)[3]; RECEIVED_HELO_LOCALHOST(0.00)[]; DMARC_NA(0.00)[pengutronix.de]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FORWARDED(0.00)[barebox@lists.infradead.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lists.infradead.org:+]; FORGED_SENDER(0.00)[a.fatoum@pengutronix.de,barebox-bounces@lists.infradead.org]; FORGED_SENDER_FORWARDING(0.00)[]; FROM_NEQ_ENVFROM(0.00)[a.fatoum@pengutronix.de,barebox-bounces@lists.infradead.org]; FROM_HAS_DN(0.00)[]; TAGGED_FROM(0.00)[lore=pengutronix.de]; NEURAL_HAM(-0.00)[-1.000]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:7247, ipnet:2607:7c80:54::/48, country:US]; FORGED_SENDER_MAILLIST(0.00)[] X-Rspamd-Action: no action Hello Sascha, On 9/4/26 1:13 PM, Sascha Hauer wrote: > On 2026-09-04 13:05, Ahmad Fatoum wrote: >> >> >> On 9/4/26 11:15 AM, Sascha Hauer wrote: >>> f_size is an alias for the inode's i_size, and filesystems read that >>> size straight from untrusted media. ext4's ext4_isize() builds it as >>> ((loff_t)size_high << 32) | size, so bit 31 of size_high lands in the >>> sign bit; squashfs takes an unchecked le64 for LREG inodes. A negative >>> i_size then feeds the offset arithmetic in __read(), __write() and >>> friends, where it either wraps a size_t count to something huge or -- >>> depending on whether size_t is 32 or 64 bit -- turns the comparison >>> unsigned and skips the EOF clamp altogether. >>> >>> Catch this the way Linux does: give the superblock a ceiling and refuse >>> sizes beyond it, instead of hardening every arithmetic site. Default >>> s_maxbytes to MAX_LFS_FILESIZE in init_super(), which runs before the >>> driver probe, so the filesystems that already lower it (jffs2, ubifs, >>> squashfs, 9p) keep doing so and everyone else stops sitting at zero. >>> >>> The check goes into do_dentry_open() rather than into iget: ten drivers >>> only learn the size in their ->open() callback and write it to the >>> inode through file->f_size, so a lookup time check would miss them. >>> Casting to u64 makes a negative size exceed any sane s_maxbytes, so the >>> sign is covered too; FILE_SIZE_STREAM is negative on purpose and has to >>> be excluded. >>> >>> Assisted-by: Claude:claude-opus-5 >>> Signed-off-by: Sascha Hauer >>> --- >>> fs/fs.c | 15 +++++++++++++++ >>> 1 file changed, 15 insertions(+) >>> >>> diff --git a/fs/fs.c b/fs/fs.c >>> index ce41f23f88..9518f28539 100644 >>> --- a/fs/fs.c >>> +++ b/fs/fs.c >>> @@ -986,6 +986,7 @@ int fsdev_open_cdev(struct fs_device *fsdev) >>> static void init_super(struct super_block *sb) >>> { >>> INIT_LIST_HEAD(&sb->s_inodes); >>> + sb->s_maxbytes = MAX_LFS_FILESIZE; >>> } >>> >>> static int fsdev_umount(struct fs_device *fsdev) >>> @@ -2613,6 +2614,14 @@ static int rmdirat(int dirfd, const char *pathname) >>> return errno_set(error); >>> } >>> >>> +static bool i_size_valid(struct inode *inode) >>> +{ >>> + if (inode->i_size == FILE_SIZE_STREAM) >>> + return true; >> >> Is FILE_SIZE_STREAM not a barebox convention? Couldn't a file system >> have on disk FILE_SIZE_STREAM and trigger misbehavior this way? > > Hm, right. At this point we cannot distinguish between a valid > FILE_SIZE_STREAM and a value from a corrupted filesystem. Maybe we > should make this an extra field in struct inode rather than overloading > i_size with this information. Sounds good. > > Sascha > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |