+jaeguk,chao,peterz,mingo,longman,boqun.feng (F2FS and Lockdep maintainers) On Sun, Nov 13, 2022 at 02:55:47PM -0800, syzbot wrote: > syzbot has found a reproducer for the following issue on: > > HEAD commit: af7a05689189 Merge tag 'mips-fixes_6.1_1' of git://git.ker.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=175bb059880000 > kernel config: https://syzkaller.appspot.com/x/.config?x=cbbe7c32024f5b72 > dashboard link: https://syzkaller.appspot.com/bug?extid=ea70429cd5cf47ba8937 > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10930249880000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11af96ae880000 This looks like it's either a f2fs or lockdep bug. To trigger the crash, the reproducer is mounting and unmounting the f2fs file system a huge number of times, and then ext4 calls lockdep_set_subclass which then triggers a KASAN report: BUG: KASAN: slab-out-of-bounds in lockdep_set_quota_inode fs/ext4/super.c:6803 [inline] On fs/ext4/super.c:6803 is the call to lockdep_set_subclass: lockdep_set_subclass(&ei->i_data_sem, subclass); So the KASAN failure is coming from some kind of out-of-bounds pointer dereference inside lockdep's internal data structures: kasan_report+0xcd/0x100 mm/kasan/report.c:495 lockdep_set_quota_inode fs/ext4/super.c:6803 [inline] ext4_quota_enable fs/ext4/super.c:6913 [inline] ext4_enable_quotas+0x577/0xcf0 fs/ext4/super.c:6940 __ext4_fill_super fs/ext4/super.c:5500 [inline] ext4_fill_super+0x7ee4/0x8610 fs/ext4/super.c:5643 get_tree_bdev+0x400/0x620 fs/super.c:1324 vfs_get_tree+0x88/0x270 fs/super.c:1531 do_new_mount+0x289/0xad0 fs/namespace.c:3040 do_mount fs/namespace.c:3383 [inline] ... and *this* is why we need to have a way to assign a syzkaller report to a different subsystem than the apparent one in the syzkaller title: KASAN: slab-out-of-bounds Read in ext4_enable_quotas Attached is the result of running the repro on KVM. Note the of the 30626 lines in the log, 26,192 lines mention f2fs, and 321 lines mention ext4, since the repro seems to result in repeatedly trying to mount corrupt f2fs and ext4 file system until something creaks. I'm waiting for some Red Hat principle engineer to file a high severity CVE because "someone might trick a root user to run the reproducer"[1][2] <rolls eye> [1] CVE-2022-1304 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2069726 - Ted
Attachment:
log.202211132336.xz
Description: application/xz
