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
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/78620ee9e532/disk-af7a0568.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2155a76a6304/vmlinux-af7a0568.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3d4c407e5692/bzImage-af7a0568.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/6bdee54735f1/mount_0.gz
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/7fefac3c26b8/mount_1.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
loop5: detected capacity change from 0 to 264192
==================================================================
BUG: KASAN: slab-out-of-bounds in lockdep_set_quota_inode fs/ext4/super.c:6803 [inline]
BUG: KASAN: slab-out-of-bounds in ext4_quota_enable fs/ext4/super.c:6913 [inline]
BUG: KASAN: slab-out-of-bounds in ext4_enable_quotas+0x577/0xcf0 fs/ext4/super.c:6940
Read of size 8 at addr ffff88806e14ffd8 by task syz-executor602/14324
CPU: 0 PID: 14324 Comm: syz-executor602 Not tainted 6.1.0-rc4-syzkaller-00372-gaf7a05689189 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
print_address_description+0x74/0x340 mm/kasan/report.c:284
print_report+0x107/0x1f0 mm/kasan/report.c:395
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]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f4d005b102a
Code: 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 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:00007f4d0055a138 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f4d005b102a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007f4d0055a180
RBP: 0000000000000004 R08: 00007f4d0055a1c0 R09: 00007f4d0055a1f0
R10: 0000000000000000 R11: 0000000000000202 R12: 00007f4d0055a1c0
R13: 0000000000000029 R14: 00007f4d0055a180 R15: 00000000200005d8
</TASK>
Allocated by task 13530:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
__kasan_slab_alloc+0x65/0x70 mm/kasan/common.c:325
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3398 [inline]
slab_alloc mm/slub.c:3406 [inline]
__kmem_cache_alloc_lru mm/slub.c:3413 [inline]
kmem_cache_alloc_lru+0x180/0x2e0 mm/slub.c:3429
alloc_inode_sb include/linux/fs.h:3117 [inline]
f2fs_alloc_inode+0x14d/0x520 fs/f2fs/super.c:1366
alloc_inode fs/inode.c:259 [inline]
iget_locked+0x191/0x830 fs/inode.c:1286
f2fs_iget+0x51/0x4bb0 fs/f2fs/inode.c:505
f2fs_fill_super+0x5382/0x6c40 fs/f2fs/super.c:4341
mount_bdev+0x26c/0x3a0 fs/super.c:1401
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
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]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Last potentially related work creation:
kasan_save_stack+0x2b/0x50 mm/kasan/common.c:45
__kasan_record_aux_stack+0xb0/0xc0 mm/kasan/generic.c:481
call_rcu+0x163/0x9c0 kernel/rcu/tree.c:2798
f2fs_fill_super+0x5669/0x6c40 fs/f2fs/super.c:4516
mount_bdev+0x26c/0x3a0 fs/super.c:1401
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
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]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Second to last potentially related work creation:
kasan_save_stack+0x2b/0x50 mm/kasan/common.c:45
__kasan_record_aux_stack+0xb0/0xc0 mm/kasan/generic.c:481
call_rcu+0x163/0x9c0 kernel/rcu/tree.c:2798
f2fs_fill_super+0x5669/0x6c40 fs/f2fs/super.c:4516
mount_bdev+0x26c/0x3a0 fs/super.c:1401
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
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]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The buggy address belongs to the object at ffff88806e14f360
which belongs to the cache f2fs_inode_cache of size 2144
The buggy address is located 1048 bytes to the right of
2144-byte region [ffff88806e14f360, ffff88806e14fbc0)
The buggy address belongs to the physical page:
page:ffffea0001b85200 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88806e14ac60 pfn:0x6e148
head:ffffea0001b85200 order:3 compound_mapcount:0 compound_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffffea0001b89a08 ffffea0001bdbe08 ffff888146d52640
raw: ffff88806e14ac60 00000000000e000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 11995, tgid 11991 (syz-executor602), ts 992233933290, free_ts 11204603085
prep_new_page mm/page_alloc.c:2539 [inline]
get_page_from_freelist+0x742/0x7c0 mm/page_alloc.c:4288
__alloc_pages+0x259/0x560 mm/page_alloc.c:5555
alloc_slab_page+0x70/0xf0 mm/slub.c:1794
allocate_slab+0x5e/0x4b0 mm/slub.c:1939
new_slab mm/slub.c:1992 [inline]
___slab_alloc+0x782/0xe20 mm/slub.c:3180
__slab_alloc mm/slub.c:3279 [inline]
slab_alloc_node mm/slub.c:3364 [inline]
slab_alloc mm/slub.c:3406 [inline]
__kmem_cache_alloc_lru mm/slub.c:3413 [inline]
kmem_cache_alloc_lru+0x233/0x2e0 mm/slub.c:3429
alloc_inode_sb include/linux/fs.h:3117 [inline]
f2fs_alloc_inode+0x14d/0x520 fs/f2fs/super.c:1366
alloc_inode fs/inode.c:259 [inline]
iget_locked+0x191/0x830 fs/inode.c:1286
f2fs_iget+0x51/0x4bb0 fs/f2fs/inode.c:505
f2fs_fill_super+0x52c4/0x6c40 fs/f2fs/super.c:4333
mount_bdev+0x26c/0x3a0 fs/super.c:1401
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
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]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1459 [inline]
free_pcp_prepare+0x80c/0x8f0 mm/page_alloc.c:1509
free_unref_page_prepare mm/page_alloc.c:3387 [inline]
free_unref_page+0x7d/0x5f0 mm/page_alloc.c:3483
free_contig_range+0xa3/0x160 mm/page_alloc.c:9493
destroy_args+0xfe/0x935 mm/debug_vm_pgtable.c:1031
debug_vm_pgtable+0x44d/0x4a6 mm/debug_vm_pgtable.c:1354
do_one_initcall+0x1c9/0x400 init/main.c:1303
do_initcall_level+0x168/0x218 init/main.c:1376
do_initcalls+0x4b/0x8c init/main.c:1392
kernel_init_freeable+0x428/0x5d5 init/main.c:1631
kernel_init+0x19/0x2b0 init/main.c:1519
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
Memory state around the buggy address:
ffff88806e14fe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88806e14ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88806e14ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88806e150000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88806e150080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
+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
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
On Mon, Nov 14, 2022 at 11:21:33AM -0500, Waiman Long wrote:
>
> 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?
Well, the inode pointer would be coming from iget(). And since this
is coming from ext4 mount operation, we would be getting a fresh inode
that should be freshly allocated. So the possibilities which comes to
mind is some kind of use-after-free (probbly in f2fs) that was
smashing the inode itself, such that ei->i_data_sem was pointing off
into la-la-land, or in the inode cache's internal data srtuctures.
The reason why I would assume it would be in f2fs is I *assume*
syzkaller would have pruned down the test case enough to remove the
messing around with mounting the invalid f2fs file system. But the
other mystery here is why didn't KASAN report the use-after-free (if
that it is what it was) in the thousands of f2fs mount and
unmount operations before it finally triggered?
Anyway, I plan to ignore this Syzkaller unless report Syzkaller (or
someone else) can come up with a more minimal/reliable reproducer. (I
mean, we could open a bug, but with kind of reproducer, it would get
prioritized P3 or P4 and ignored for years until it finally got closed
in a buganizer bankruptcy, so I figured I would just skip a few steps. :-)
Cheers,
- Ted
On Mon, 14 Nov 2022 at 18:53, Theodore Ts'o <[email protected]> wrote:
>
> On Mon, Nov 14, 2022 at 11:21:33AM -0500, Waiman Long wrote:
> >
> > 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?
>
> Well, the inode pointer would be coming from iget(). And since this
> is coming from ext4 mount operation, we would be getting a fresh inode
> that should be freshly allocated. So the possibilities which comes to
> mind is some kind of use-after-free (probbly in f2fs) that was
> smashing the inode itself, such that ei->i_data_sem was pointing off
> into la-la-land, or in the inode cache's internal data srtuctures.
>
> The reason why I would assume it would be in f2fs is I *assume*
> syzkaller would have pruned down the test case enough to remove the
> messing around with mounting the invalid f2fs file system. But the
> other mystery here is why didn't KASAN report the use-after-free (if
> that it is what it was) in the thousands of f2fs mount and
> unmount operations before it finally triggered?
>
> Anyway, I plan to ignore this Syzkaller unless report Syzkaller (or
> someone else) can come up with a more minimal/reliable reproducer. (I
> mean, we could open a bug, but with kind of reproducer, it would get
> prioritized P3 or P4 and ignored for years until it finally got closed
> in a buganizer bankruptcy, so I figured I would just skip a few steps. :-)
Let's set the subsystem then, so it's in the f2fs bucket rather than in ext4:
#syz set subsystems: f2fs