Re: [PATCH] ufs: reject inconsistent on-disk fshift

[Al Viro <viro@zeniv.linux.org.uk>]

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.