From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCADC3C2796 for ; Tue, 26 May 2026 22:44:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779835496; cv=none; b=GVa2eAexBFO7KjW4TpqxFO0KlevlEPkVPTAqyOkz3c4jG9zBy9+5U9Bsxn9JmZboOf1hIEU7wKAdU8OssGMVHVBLWhA6Doc0xLq1Q1v20/51syUCT8u7nhjsJAdPSlXXRGnlMnTfzZ+q+iueY3GMFYReLThEqDprX4/P15IxnKg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779835496; c=relaxed/simple; bh=qHvxSvLxDvMbT/0m+VdAOpK2SUYvcVM/LJ/FkUqXKbo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K0ADors6OK7WiQWU9wZP1xYaskD7ivZLrl+GhLiT55o0u58AC6qkmZP8YVfKWEKZjNKb7ahjuAfGV8JjjkloP2qjvkSK/gWjZfxAoXmRfBEQc0GDqeWW0TkSYTN+G+HRSIADLkXq7cHpnERqszbS40lTeogZIHBBxl/tiNSGidU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=sSapXdmL; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="sSapXdmL" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=clQwo/IjS2IqkSzPfZVTECWDo8YaOIyG+t/sTtBPf+E=; b=sSapXdmL0Wg5O2NMX+3/RE/wPU f+9mApttH/Bj+DLBxg8weOzgGs2xwX6mGKwP8fcptG7lGMCS717FHR8zH4rlab4IeVL1Mj8ZHLnCQ yr5+6VY6G5EcwpHn54NBJDQDjsew9aDVGCK1iOfhqjsIvdky4apuZDalrIOMHHrEWS56QU9OwDww4 2RQW7JdkyUXcwsdWU2EdrJ4dmLt/CIYdRMDKiIyUqbVd1zhEvUHX+i0k59WgaL5iliJ69YAR3Oyi9 BCpVIGMpy834yE2uOWz895Oihq3EO5EI5/nisgA9kxZi5UpvLCb4PMWb59miF61lW57mDnaZvFTzi 9+PSVMIA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.2 #2 (Red Hat Linux)) id 1wS0W3-00000008tVO-2UJo; Tue, 26 May 2026 22:44:51 +0000 Date: Tue, 26 May 2026 23:44:51 +0100 From: Al Viro To: Farhad Alemi Cc: Kees Cook , linux-kernel@vger.kernel.org Subject: Re: [PATCH] ufs: reject inconsistent on-disk fshift Message-ID: <20260526224451.GE2636677@ZenIV> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro On Mon, May 25, 2026 at 06:50:53PM -0700, Farhad Alemi wrote: > ufs_fill_super() reads uspi->s_fshift directly from the on-disk > superblock (usb1->fs_fshift) and later uses it as the shift exponent in > ubh_bread_uspi(), without checking that it matches the already-validated > s_fsize. The s_fsize/s_bsize range and power-of-two checks at the same > site leave s_fshift unverified, so a crafted image can supply a valid > s_fsize and an out-of-range s_fshift, take the "goto again" path back > to the second ubh_bread_uspi() call, and trigger UBSAN on the > size >> uspi->s_fshift expression: > > UBSAN: shift-out-of-bounds in fs/ufs/util.c:55:15 > shift exponent 8454156 is too large for 64-bit type 'u64' > Call Trace: > __ubsan_handle_shift_out_of_bounds+0x385/0x410 lib/ubsan.c:494 > ubh_bread_uspi+0x37e/0x390 fs/ufs/util.c:55 > ufs_fill_super+0x1412/0x75c0 fs/ufs/super.c:936 > get_tree_bdev_flags+0x436/0x500 fs/super.c:1698 > vfs_get_tree+0x97/0x2b0 fs/super.c:1758 > do_new_mount+0x32e/0xa50 fs/namespace.c:3728 > __se_sys_mount+0x322/0x420 fs/namespace.c:4216 > > With panic_on_warn this is promoted to a kernel panic. Trigger requires > the ability to mount a crafted image (CAP_SYS_ADMIN or equivalent). > > s_fshift and s_fsize encode the same value redundantly: s_fshift is > ilog2(s_fsize). Since s_fsize is already validated to be a power of two > in [512, 4096] just above, require s_fshift to equal ilog2(s_fsize) > and reject the image otherwise. This also protects the many other > shifts that consume uspi->s_fshift across fs/ufs/. That needs a lot more validation - as it is, if filesystem is *not* valid according to native fsck (Debian archive has old ufstools, with fsck.ufs in it), do not try to mount it. I've a half-baked patch sitting in my local tree with such checks, need to resurrect it... Until it's there, don't bother with fuzzers - no point.