[BUG] UBSAN: Shift-Out-of-Bounds in befs_check_sb (BeFS) on 6.14.0-rc4 - Possible Regression**

[Strforexc yn]

Dear Linux Kernel Developers,
I’ve encountered a UBSAN-reported shift-out-of-bounds issue in the
BeFS filesystem on Linux 6.14.0-rc4 during superblock validation,
which may indicate a regression from prior fixes. Here are the
details:

Kernel commit: v6.14-rc4 (Commits on Feb 24, 2025)
Kernel Config : https://github.com/Strforexc/LinuxKernelbug/blob/main/.config
Kernel Log:  https://github.com/Strforexc/LinuxKernelbug/blob/main/shift-out-of-bounds_befs_check_sb/log0
Reproduce C: https://github.com/Strforexc/LinuxKernelbug/blob/main/shift-out-of-bounds_befs_check_sb/repro.cprog

Bug Description:
UBSAN detects a shift-out-of-bounds in fs/befs/super.c:96:9, where a
shift exponent of 3229888891 exceeds the 32-bit int limit in
befs_check_sb. This occurs when mounting a BeFS filesystem with a
potentially malformed superblock.

Location: The fault occurs at (1 << befs_sb->block_shift) in
befs_check_sb, where block_shift (a __u32) is 3229888891, exceeding
the 32-bit shift limit (31).

Cause: No bounds check exists for block_shift before the shift
operation, allowing garbage or malicious values from a crafted
superblock to trigger undefined behavior.

Context: Syzkaller’s mount of a BeFS filesystem on loop0 likely
provided a malformed superblock.

Impact: Undefined shift behavior could crash the kernel or corrupt
memory, posing a DoS risk with malicious filesystems. UBSAN warns
here, but production kernels may fail silently.

Could BeFS maintainers investigate? This seems like a regression from
prior superblock validation fixes. Suggested actions:
1. Add a bounds check: if (befs_sb->block_shift > 31) { befs_error(sb,
"invalid block_shift: %u", befs_sb->block_shift); return BEFS_ERR; }.
2. Review historical BeFS patches to confirm if block_shift validation
was dropped.

Our knowledge of the kernel is somewhat limited, and we'd appreciate
it if you could determine if there is such an issue. If this issue
doesn't have an impact, please ignore it ☺.
If you fix this issue, please add the following tag to the commit:
Reported-by: Zhizhuo Tang <strforexctzzchange@xxxxxxxxxxx>, Jianzhou
Zhao <xnxc22xnxc22@xxxxxx>, Haoran Liu <cherest_san@xxxxxxx>

================================================================
loop0: detected capacity change from 0 to 128
------------[ cut here ]------------
UBSAN: shift-out-of-bounds in fs/befs/super.c:96:9
shift exponent 3229888891 is too large for 32-bit type 'int'
CPU: 1 UID: 0 PID: 11513 Comm: syz.0.10 Not tainted 6.14.0-rc4 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x180/0x1b0 lib/dump_stack.c:120
 ubsan_epilogue lib/ubsan.c:231 [inline]
 __ubsan_handle_shift_out_of_bounds+0x1d2/0x350 lib/ubsan.c:468
 befs_check_sb.cold+0x19/0x6f fs/befs/super.c:96
 befs_fill_super+0x59f/0xcc0 fs/befs/linuxvfs.c:841
 get_tree_bdev_flags+0x396/0x630 fs/super.c:1636
 vfs_get_tree+0x93/0x350 fs/super.c:1814
 do_new_mount+0x368/0x730 fs/namespace.c:3560
 path_mount+0x4a6/0x17f0 fs/namespace.c:3887
 do_mount fs/namespace.c:3900 [inline]
 __do_sys_mount fs/namespace.c:4111 [inline]
 __se_sys_mount fs/namespace.c:4088 [inline]
 __x64_sys_mount+0x288/0x310 fs/namespace.c:4088
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcb/0x260 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fafc99ba41e
Code: 48 c7 c0 ff ff ff ff eb aa e8 5e 20 00 00 66 2e 0f 1f 84 00 00
00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fafca8b7da8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000009e24 RCX: 00007fafc99ba41e
RDX: 0000400000000100 RSI: 0000400000009e40 RDI: 00007fafca8b7e00
RBP: 00007fafca8b7e40 R08: 00007fafca8b7e40 R09: 0000000003008001
R10: 0000000003008001 R11: 0000000000000246 R12: 0000400000000100
R13: 0000400000009e40 R14: 00007fafca8b7e00 R15: 00004000000001c0
 </TASK>
---[ end trace ]---

Regards,
Strforexc