On 11/14/22 10:16, Theodore Ts'o wrote:
+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]
lockdep_set_subclass() should be translated into a call to
lockdep_init_map_type():
#define lockdep_set_subclass(lock, sub) \
lockdep_init_map_type(&(lock)->dep_map, #lock,
(lock)->dep_map.key, sub,\
(lock)->dep_map.wait_type_inner, \
(lock)->dep_map.wait_type_outer, \
(lock)->dep_map.lock_type)
All memory access should be within the bound of the given
"&ei->i_data_sem". Also lockdep_init_map_type() is not in the stack
trace. So it is not a problem within this lockdep_init_map_type()
function. So is it possible that the given inode pointer is invalid?
Cheers,
Longman
