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/.

Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Signed-off-by: Farhad Alemi <farhad.alemi@berkeley.edu>
---
 fs/ufs/super.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index c4831a8b9b3f..dc3b4956faeb 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -1018,6 +1018,11 @@ static int ufs_fill_super(struct super_block
*sb, struct fs_context *fc)
 		       __func__, uspi->s_fsize);
 		goto failed;
 	}
+	if (uspi->s_fshift != ilog2(uspi->s_fsize)) {
+		pr_err("%s(): inconsistent fshift %u for fsize %u\n",
+		       __func__, uspi->s_fshift, uspi->s_fsize);
+		goto failed;
+	}
 	if (!is_power_of_2(uspi->s_bsize)) {
 		pr_err("%s(): block size %u is not a power of 2\n",
 		       __func__, uspi->s_bsize);
-- 
2.43.0

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.