[syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext4_handle_clustersize

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 1b29d271614a Merge tag 'staging-6.4-rc7' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15fefd03280000
kernel config: https://syzkaller.appspot.com/x/.config?x=7ff8f87c7ab0e04e
dashboard link: https://syzkaller.appspot.com/bug?extid=f4cf49c6365d87eb8e0e
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/bd5aafc3a720/disk-1b29d271.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6689979a4ad9/vmlinux-1b29d271.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7f1acb11ce85/bzImage-1b29d271.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f4cf49...@syzkaller.appspotmail.com

UBSAN: shift-out-of-bounds in fs/ext4/super.c:4401:27
shift exponent 374 is too large for 32-bit type 'int'
CPU: 0 PID: 27421 Comm: syz-executor.0 Not tainted 6.4.0-rc6-syzkaller-00269-g1b29d271614a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_shift_out_of_bounds+0x3c3/0x420 lib/ubsan.c:387
ext4_handle_clustersize+0x592/0x5c0 fs/ext4/super.c:4401
__ext4_fill_super fs/ext4/super.c:5279 [inline]
ext4_fill_super+0x3a66/0x6c60 fs/ext4/super.c:5672
get_tree_bdev+0x405/0x620 fs/super.c:1303
vfs_get_tree+0x8c/0x270 fs/super.c:1510
do_new_mount+0x28f/0xae0 fs/namespace.c:3039
do_mount fs/namespace.c:3382 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f7e1888d8ba
Code: 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 b8 04 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f7e195cef88 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 000000000000043c RCX: 00007f7e1888d8ba
RDX: 0000000020000440 RSI: 0000000020000180 RDI: 00007f7e195cefe0
RBP: 00007f7e195cf020 R08: 00007f7e195cf020 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000020000440
R13: 0000000020000180 R14: 00007f7e195cefe0 R15: 00000000200001c0
</TASK>
================================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Theodore Ts'o]

On Thu, Jun 22, 2023 at 05:01:44AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 1b29d271614a Merge tag 'staging-6.4-rc7' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15fefd03280000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7ff8f87c7ab0e04e
> dashboard link: https://syzkaller.appspot.com/bug?extid=f4cf49c6365d87eb8e0e
> compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.

> UBSAN: shift-out-of-bounds in fs/ext4/super.c:4401:27
> shift exponent 374 is too large for 32-bit type 'int'

fs/ext4/super.c:4401 is:

clustersize = BLOCK_SIZE << le32_to_cpu(es->s_log_cluster_size);

... however earlier, in ext4_load_super() we check to make sure that
(es->s_log_cluster_size) is no more than 20 (EXT4_MAX_BLOCK_LOG_SIZE -
EXT4_MIN_BLOCK_LOG_SIZE).

So it's likely this is either a while pointer corrupting the
superblock after we've checked the value, but before we try to use it
later.... or this is another "some thread is actively writing to the
block device while we are in the process of mounting the file system".

Since it's only occurred once, and we have no reproducer, it's
impossible to say, but we'll just ignore this for now.

- Ted

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.