[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211213120745.2kzg4sazidh45cje@wittgenstein>
Date: Mon, 13 Dec 2021 13:07:45 +0100
From: Christian Brauner <christian.brauner@...ntu.com>
To: syzbot <syzbot+5ad0824204c7bf9b67f2@...kaller.appspotmail.com>
Cc: akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
jack@...e.cz, jamorris@...ux.microsoft.com,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] UBSAN: shift-out-of-bounds in minix_statfs
On Sun, Dec 12, 2021 at 11:17:25PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: b8a98b6bf66a Merge tag 'pci-v5.16-fixes-2' of git://git.ke..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1342c069b00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=221ffc09e39ebbd1
> dashboard link: https://syzkaller.appspot.com/bug?extid=5ad0824204c7bf9b67f2
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15e8a551b00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=176da9b9b00000
>
> Bisection is inconclusive: the issue happens on the oldest tested release.
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17e8a7bdb00000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1418a7bdb00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1018a7bdb00000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5ad0824204c7bf9b67f2@...kaller.appspotmail.com
This looks like minix isn't verifying the image it has been passed
sufficiently. Specifically, the reproducer might encode an invalid block
size but it's hard to make sense of all the raw addresses in the
reproducer. isofs has
/* RDE: convert log zone size to bit shift */
switch (sbi->s_log_zone_size) {
case 512: sbi->s_log_zone_size = 9; break;
case 1024: sbi->s_log_zone_size = 10; break;
case 2048: sbi->s_log_zone_size = 11; break;
default:
goto out_bad_zone_size;
}
minix has nothing so I'd expect it to be possible to pass
50000000000000000
as log zone size and minix would just use it causing the issue in
minix_statfs() you're seeing.
While that could be fixed I wonder if we shouldn't just mark minixfs as
broken. But I seriously have no clue who is using this fs for what.
>
> loop0: detected capacity change from 0 to 272
> ================================================================================
> UBSAN: shift-out-of-bounds in fs/minix/inode.c:380:57
> shift exponent 65510 is too large for 64-bit type 'long unsigned int'
> CPU: 0 PID: 3601 Comm: syz-executor657 Not tainted 5.16.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> ubsan_epilogue+0xb/0x5a lib/ubsan.c:151
> __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:330
> minix_statfs.cold+0x17/0x1c fs/minix/inode.c:380
> statfs_by_dentry+0x133/0x210 fs/statfs.c:66
> vfs_statfs fs/statfs.c:90 [inline]
> fd_statfs+0x66/0x100 fs/statfs.c:120
> __do_sys_fstatfs+0x7a/0xf0 fs/statfs.c:216
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x7f33e4f00e09
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffeedacabd8 EFLAGS: 00000246 ORIG_RAX: 000000000000008a
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f33e4f00e09
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
> RBP: 00007f33e4ec06a0 R08: 0000000000000000 R09: 0000000000000000
> R10: 00007ffeedacaa90 R11: 0000000000000246 R12: 00007f33e4ec0730
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> </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 syzkaller@...glegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
Powered by blists - more mailing lists