* [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
@ 2022-09-26 11:46 syzbot
2022-11-13 22:55 ` syzbot
0 siblings, 1 reply; 6+ messages in thread
From: syzbot @ 2022-09-26 11:46 UTC (permalink / raw)
To: adilger.kernel, linux-ext4, linux-kernel, llvm, nathan,
ndesaulniers, syzkaller-bugs, trix, tytso
Hello,
syzbot found the following issue on:
HEAD commit: bf682942cd26 Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12e7f318880000
kernel config: https://syzkaller.appspot.com/x/.config?x=c221af36f6d1d811
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
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/a27f1315833f/disk-bf682942.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/10067330020a/vmlinux-bf682942.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ea70429cd5cf47ba8937@syzkaller.appspotmail.com
loop0: detected capacity change from 0 to 4096
==================================================================
BUG: KASAN: slab-out-of-bounds in lockdep_set_quota_inode fs/ext4/super.c:6677 [inline]
BUG: KASAN: slab-out-of-bounds in ext4_quota_enable fs/ext4/super.c:6787 [inline]
BUG: KASAN: slab-out-of-bounds in ext4_enable_quotas+0x577/0xcf0 fs/ext4/super.c:6814
Read of size 8 at addr ffff8880512c1a60 by task syz-executor.0/14097
CPU: 0 PID: 14097 Comm: syz-executor.0 Not tainted 6.0.0-rc6-syzkaller-00210-gbf682942cd26 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/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+0x65/0x4b0 mm/kasan/report.c:317
print_report+0x108/0x1f0 mm/kasan/report.c:433
kasan_report+0xc3/0xf0 mm/kasan/report.c:495
lockdep_set_quota_inode fs/ext4/super.c:6677 [inline]
ext4_quota_enable fs/ext4/super.c:6787 [inline]
ext4_enable_quotas+0x577/0xcf0 fs/ext4/super.c:6814
__ext4_fill_super+0x9305/0x9a10 fs/ext4/super.c:5363
ext4_fill_super+0x313/0x700 fs/ext4/super.c:5517
get_tree_bdev+0x400/0x620 fs/super.c:1323
vfs_get_tree+0x88/0x270 fs/super.c:1530
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:0x7f473308bb9a
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:00007f4731ffdf88 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000020000200 RCX: 00007f473308bb9a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007f4731ffdfe0
RBP: 00007f4731ffe020 R08: 00007f4731ffe020 R09: 0000000020000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000020000000
R13: 0000000020000100 R14: 00007f4731ffdfe0 R15: 0000000020000080
</TASK>
Allocated by task 8066:
kasan_save_stack mm/kasan/common.c:38 [inline]
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
__kasan_slab_alloc+0xa3/0xd0 mm/kasan/common.c:470
kasan_slab_alloc include/linux/kasan.h:224 [inline]
slab_post_alloc_hook mm/slab.h:727 [inline]
slab_alloc_node mm/slub.c:3248 [inline]
slab_alloc mm/slub.c:3256 [inline]
__kmem_cache_alloc_lru mm/slub.c:3263 [inline]
kmem_cache_alloc_lru+0x175/0x2d0 mm/slub.c:3280
alloc_inode_sb include/linux/fs.h:3103 [inline]
f2fs_alloc_inode+0x14d/0x520 fs/f2fs/super.c:1361
alloc_inode fs/inode.c:260 [inline]
iget_locked+0x191/0x830 fs/inode.c:1287
f2fs_iget+0x52/0x4930 fs/f2fs/inode.c:489
f2fs_fill_super+0x4fd6/0x6c90 fs/f2fs/super.c:4265
mount_bdev+0x26c/0x3a0 fs/super.c:1400
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
vfs_get_tree+0x88/0x270 fs/super.c:1530
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:38
__kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:348
call_rcu+0x163/0x970 kernel/rcu/tree.c:2793
f2fs_fill_super+0x537b/0x6c90 fs/f2fs/super.c:4448
mount_bdev+0x26c/0x3a0 fs/super.c:1400
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
vfs_get_tree+0x88/0x270 fs/super.c:1530
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 ffff8880512c11b0
which belongs to the cache f2fs_inode_cache of size 2136
The buggy address is located 88 bytes to the right of
2136-byte region [ffff8880512c11b0, ffff8880512c1a08)
The buggy address belongs to the physical page:
page:ffffea000144b000 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880512c2c38 pfn:0x512c0
head:ffffea000144b000 order:3 compound_mapcount:0 compound_pincount:0
memcg:ffff88807cbb6e01
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 0000000000000000 dead000000000122 ffff88801bf883c0
raw: ffff8880512c2c38 00000000800e0009 00000001ffffffff ffff88807cbb6e01
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 7508, tgid 7507 (syz-executor.5), ts 142200130740, free_ts 141953283665
prep_new_page mm/page_alloc.c:2532 [inline]
get_page_from_freelist+0x742/0x7c0 mm/page_alloc.c:4283
__alloc_pages+0x259/0x560 mm/page_alloc.c:5515
alloc_slab_page+0x70/0xf0 mm/slub.c:1829
allocate_slab+0x5e/0x520 mm/slub.c:1974
new_slab mm/slub.c:2034 [inline]
___slab_alloc+0x3ee/0xc40 mm/slub.c:3036
__slab_alloc mm/slub.c:3123 [inline]
slab_alloc_node mm/slub.c:3214 [inline]
slab_alloc mm/slub.c:3256 [inline]
__kmem_cache_alloc_lru mm/slub.c:3263 [inline]
kmem_cache_alloc_lru+0x225/0x2d0 mm/slub.c:3280
alloc_inode_sb include/linux/fs.h:3103 [inline]
f2fs_alloc_inode+0x14d/0x520 fs/f2fs/super.c:1361
alloc_inode fs/inode.c:260 [inline]
iget_locked+0x191/0x830 fs/inode.c:1287
f2fs_iget+0x52/0x4930 fs/f2fs/inode.c:489
f2fs_fill_super+0x38c1/0x6c90 fs/f2fs/super.c:4157
mount_bdev+0x26c/0x3a0 fs/super.c:1400
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
vfs_get_tree+0x88/0x270 fs/super.c:1530
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:1449 [inline]
free_pcp_prepare+0x812/0x900 mm/page_alloc.c:1499
free_unref_page_prepare mm/page_alloc.c:3380 [inline]
free_unref_page+0x7d/0x5f0 mm/page_alloc.c:3476
qlist_free_all+0x2b/0x70 mm/kasan/quarantine.c:187
kasan_quarantine_reduce+0x169/0x180 mm/kasan/quarantine.c:294
__kasan_slab_alloc+0x2f/0xd0 mm/kasan/common.c:447
kasan_slab_alloc include/linux/kasan.h:224 [inline]
slab_post_alloc_hook mm/slab.h:727 [inline]
slab_alloc_node mm/slub.c:3248 [inline]
kmem_cache_alloc_node+0x1cc/0x350 mm/slub.c:3298
__alloc_skb+0xcf/0x2b0 net/core/skbuff.c:422
alloc_skb include/linux/skbuff.h:1257 [inline]
alloc_skb_with_frags+0xaf/0x810 net/core/skbuff.c:6021
sock_alloc_send_pskb+0x938/0xa70 net/core/sock.c:2665
unix_dgram_sendmsg+0x5ab/0x2010 net/unix/af_unix.c:1912
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
sock_write_iter+0x3d4/0x540 net/socket.c:1108
call_write_iter include/linux/fs.h:2187 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x7dc/0xc50 fs/read_write.c:578
ksys_write+0x177/0x2a0 fs/read_write.c:631
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
Memory state around the buggy address:
ffff8880512c1900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880512c1980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880512c1a00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8880512c1a80: fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880512c1b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
---
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@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
2022-09-26 11:46 [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas syzbot
@ 2022-11-13 22:55 ` syzbot
2022-11-14 15:16 ` Theodore Ts'o
0 siblings, 1 reply; 6+ messages in thread
From: syzbot @ 2022-11-13 22:55 UTC (permalink / raw)
To: adilger.kernel, linux-ext4, linux-kernel, llvm, nathan,
ndesaulniers, syzkaller-bugs, trix, tytso
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: syzbot+ea70429cd5cf47ba8937@syzkaller.appspotmail.com
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
==================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
2022-11-13 22:55 ` syzbot
@ 2022-11-14 15:16 ` Theodore Ts'o
2022-11-14 16:21 ` Waiman Long
0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2022-11-14 15:16 UTC (permalink / raw)
To: syzbot
Cc: adilger.kernel, linux-ext4, linux-kernel, llvm, nathan,
ndesaulniers, syzkaller-bugs, trix, Jaegeuk Kim, Chao Yu,
Peter Zijlstra, Ingo Molnar, Waiman Long, Boqun Feng
[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]
+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 #2: log.202211132336.xz --]
[-- Type: application/x-xz, Size: 193664 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
2022-11-14 15:16 ` Theodore Ts'o
@ 2022-11-14 16:21 ` Waiman Long
2022-11-14 17:53 ` Theodore Ts'o
0 siblings, 1 reply; 6+ messages in thread
From: Waiman Long @ 2022-11-14 16:21 UTC (permalink / raw)
To: Theodore Ts'o, syzbot
Cc: adilger.kernel, linux-ext4, linux-kernel, llvm, nathan,
ndesaulniers, syzkaller-bugs, trix, Jaegeuk Kim, Chao Yu,
Peter Zijlstra, Ingo Molnar, Boqun Feng
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
2022-11-14 16:21 ` Waiman Long
@ 2022-11-14 17:53 ` Theodore Ts'o
2023-07-20 15:17 ` Dmitry Vyukov
0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2022-11-14 17:53 UTC (permalink / raw)
To: Waiman Long
Cc: syzbot, adilger.kernel, linux-ext4, linux-kernel, llvm, nathan,
ndesaulniers, syzkaller-bugs, trix, Jaegeuk Kim, Chao Yu,
Peter Zijlstra, Ingo Molnar, Boqun Feng
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
2022-11-14 17:53 ` Theodore Ts'o
@ 2023-07-20 15:17 ` Dmitry Vyukov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Vyukov @ 2023-07-20 15:17 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Waiman Long, syzbot, adilger.kernel, linux-ext4, linux-kernel,
llvm, nathan, ndesaulniers, syzkaller-bugs, trix, Jaegeuk Kim,
Chao Yu, Peter Zijlstra, Ingo Molnar, Boqun Feng
On Mon, 14 Nov 2022 at 18:53, Theodore Ts'o <tytso@mit.edu> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-07-20 15:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-26 11:46 [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas syzbot
2022-11-13 22:55 ` syzbot
2022-11-14 15:16 ` Theodore Ts'o
2022-11-14 16:21 ` Waiman Long
2022-11-14 17:53 ` Theodore Ts'o
2023-07-20 15:17 ` Dmitry Vyukov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.