[syzbot] KASAN: use-after-free Read in jbd2_journal_wait_updates

120 views
Skip to first unread message

syzbot

unread,
Feb 8, 2022, 7:49:20 AM2/8/22
to ja...@suse.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot found the following issue on:

HEAD commit: 555f3d7be91a Merge tag '5.17-rc3-ksmbd-server-fixes' of gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17e55852700000
kernel config: https://syzkaller.appspot.com/x/.config?x=88e0a6a3dbf057cf
dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b03872700000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+afa2ca...@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0xda/0x2b00 kernel/locking/lockdep.c:4897
Read of size 8 at addr ffff88807440e978 by task syz-executor.0/4247

CPU: 1 PID: 4247 Comm: syz-executor.0 Not tainted 5.17.0-rc3-syzkaller-00020-g555f3d7be91a #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+0x1dc/0x2d8 lib/dump_stack.c:106
print_address_description+0x65/0x3a0 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report+0x19a/0x1f0 mm/kasan/report.c:459
__lock_acquire+0xda/0x2b00 kernel/locking/lockdep.c:4897
lock_acquire+0x19f/0x4d0 kernel/locking/lockdep.c:5639
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:349 [inline]
jbd2_journal_wait_updates+0x2cb/0x400 fs/jbd2/transaction.c:861
jbd2_journal_lock_updates+0x33b/0x420 fs/jbd2/transaction.c:896
ext4_ioctl_checkpoint fs/ext4/ioctl.c:1085 [inline]
__ext4_ioctl fs/ext4/ioctl.c:1562 [inline]
ext4_ioctl+0x34c7/0x65d0 fs/ext4/ioctl.c:1578
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fe61dd9b059
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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe61d510168 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fe61deadf60 RCX: 00007fe61dd9b059
RDX: 0000000020000000 RSI: 000000004004662b RDI: 0000000000000003
RBP: 00007fe61ddf508d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff8864c31f R14: 00007fe61d510300 R15: 0000000000022000
</TASK>

Allocated by task 4239:
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:436 [inline]
__kasan_slab_alloc+0xb2/0xe0 mm/kasan/common.c:469
kasan_slab_alloc include/linux/kasan.h:260 [inline]
slab_post_alloc_hook mm/slab.h:732 [inline]
slab_alloc_node mm/slub.c:3230 [inline]
slab_alloc mm/slub.c:3238 [inline]
kmem_cache_alloc+0x1c9/0x310 mm/slub.c:3243
kmem_cache_zalloc include/linux/slab.h:705 [inline]
start_this_handle+0x328/0x1630 fs/jbd2/transaction.c:375
jbd2__journal_start+0x2ca/0x5b0 fs/jbd2/transaction.c:525
__ext4_journal_start_sb+0x111/0x1e0 fs/ext4/ext4_jbd2.c:105
__ext4_new_inode+0x1421/0x5740 fs/ext4/ialloc.c:1080
ext4_create+0x280/0x550 fs/ext4/namei.c:2746
lookup_open fs/namei.c:3330 [inline]
open_last_lookups fs/namei.c:3400 [inline]
path_openat+0x12ec/0x36a0 fs/namei.c:3606
do_filp_open+0x277/0x4f0 fs/namei.c:3636
do_sys_openat2+0x13b/0x500 fs/open.c:1214
do_sys_open fs/open.c:1230 [inline]
__do_sys_openat fs/open.c:1246 [inline]
__se_sys_openat fs/open.c:1241 [inline]
__x64_sys_openat+0x243/0x290 fs/open.c:1241
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae

Freed by task 4249:
kasan_save_stack mm/kasan/common.c:38 [inline]
kasan_set_track+0x4c/0x70 mm/kasan/common.c:45
kasan_set_free_info+0x1f/0x40 mm/kasan/generic.c:370
____kasan_slab_free+0x126/0x180 mm/kasan/common.c:366
kasan_slab_free include/linux/kasan.h:236 [inline]
slab_free_hook mm/slub.c:1728 [inline]
slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1754
slab_free mm/slub.c:3509 [inline]
kmem_cache_free+0xb6/0x1c0 mm/slub.c:3526
__jbd2_journal_remove_checkpoint+0x529/0x5c0 fs/jbd2/checkpoint.c:735
jbd2_log_do_checkpoint+0xe7b/0x10b0 fs/jbd2/checkpoint.c:354
jbd2_journal_flush+0x298/0xd70 fs/jbd2/journal.c:2465
ext4_ioctl_checkpoint fs/ext4/ioctl.c:1086 [inline]
__ext4_ioctl fs/ext4/ioctl.c:1562 [inline]
ext4_ioctl+0x3512/0x65d0 fs/ext4/ioctl.c:1578
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae

The buggy address belongs to the object at ffff88807440e900
which belongs to the cache jbd2_transaction_s of size 280
The buggy address is located 120 bytes inside of
280-byte region [ffff88807440e900, ffff88807440ea18)
The buggy address belongs to the page:
page:ffffea0001d10380 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7440e
head:ffffea0001d10380 order:1 compound_mapcount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 0000000000000000 dead000000000001 ffff888146724500
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 3153, ts 22972783543, free_ts 11342396906
prep_new_page mm/page_alloc.c:2434 [inline]
get_page_from_freelist+0x729/0x9e0 mm/page_alloc.c:4165
__alloc_pages+0x255/0x580 mm/page_alloc.c:5389
alloc_slab_page mm/slub.c:1799 [inline]
allocate_slab+0xce/0x3f0 mm/slub.c:1944
new_slab mm/slub.c:2004 [inline]
___slab_alloc+0x3fe/0xc30 mm/slub.c:3018
__slab_alloc mm/slub.c:3105 [inline]
slab_alloc_node mm/slub.c:3196 [inline]
slab_alloc mm/slub.c:3238 [inline]
kmem_cache_alloc+0x276/0x310 mm/slub.c:3243
kmem_cache_zalloc include/linux/slab.h:705 [inline]
start_this_handle+0x328/0x1630 fs/jbd2/transaction.c:375
jbd2__journal_start+0x2ca/0x5b0 fs/jbd2/transaction.c:525
__ext4_journal_start_sb+0x111/0x1e0 fs/ext4/ext4_jbd2.c:105
__ext4_journal_start fs/ext4/ext4_jbd2.h:326 [inline]
ext4_dirty_inode+0x8a/0x100 fs/ext4/inode.c:5899
__mark_inode_dirty+0xb6/0x8f0 fs/fs-writeback.c:2409
generic_update_time fs/inode.c:1856 [inline]
inode_update_time fs/inode.c:1869 [inline]
touch_atime+0x3ef/0x650 fs/inode.c:1941
file_accessed include/linux/fs.h:2421 [inline]
filemap_read+0x25c2/0x27f0 mm/filemap.c:2744
__kernel_read+0x5d0/0xaf0 fs/read_write.c:439
prepare_binprm fs/exec.c:1657 [inline]
search_binary_handler fs/exec.c:1711 [inline]
exec_binprm fs/exec.c:1768 [inline]
bprm_execve+0x808/0x1470 fs/exec.c:1837
do_execveat_common+0x44c/0x590 fs/exec.c:1926
do_execve fs/exec.c:1994 [inline]
__do_sys_execve fs/exec.c:2070 [inline]
__se_sys_execve fs/exec.c:2065 [inline]
__x64_sys_execve+0x8e/0xa0 fs/exec.c:2065
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1352 [inline]
free_pcp_prepare+0xd1c/0xe00 mm/page_alloc.c:1404
free_unref_page_prepare mm/page_alloc.c:3325 [inline]
free_unref_page+0x7d/0x580 mm/page_alloc.c:3404
free_contig_range+0xa4/0x100 mm/page_alloc.c:9335
destroy_args+0xfe/0x971 mm/debug_vm_pgtable.c:1018
debug_vm_pgtable+0x449/0x4a1 mm/debug_vm_pgtable.c:1332
do_one_initcall+0xbd/0x2b0 init/main.c:1300
do_initcall_level+0x14a/0x1f5 init/main.c:1373
do_initcalls+0x4b/0x8c init/main.c:1389
kernel_init_freeable+0x43a/0x5c6 init/main.c:1613
kernel_init+0x19/0x2b0 init/main.c:1502
ret_from_fork+0x1f/0x30

Memory state around the buggy address:
ffff88807440e800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88807440e880: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88807440e900: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88807440e980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88807440ea00: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Jan Kara

unread,
Feb 8, 2022, 11:14:32 AM2/8/22
to syzbot, ja...@suse.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu, Ritesh Harjani
On Tue 08-02-22 04:49:19, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 555f3d7be91a Merge tag '5.17-rc3-ksmbd-server-fixes' of gi..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17e55852700000
> kernel config: https://syzkaller.appspot.com/x/.config?x=88e0a6a3dbf057cf
> dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
> compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b03872700000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+afa2ca...@syzkaller.appspotmail.com

So the syzbot reproducer looks bogus to me but the bug is real.
jbd2_journal_wait_updates() looks at commit_transaction after dropping
j_state_lock and sleeping which is certainly prone to use-after-free
issues.

Funnily, Ritesh's removal of t_handle_lock should "fix" the problem by
removing this dereference. So Ritesh, please just add some reference to
syzbot report and maybe a backport to stable would be warranted.

Honza

--
Jan Kara <ja...@suse.com>
SUSE Labs, CR

syzbot

unread,
Feb 8, 2022, 11:19:21 PM2/8/22
to ja...@suse.com, ja...@suse.cz, linux...@vger.kernel.org, linux-...@vger.kernel.org, rit...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
syzbot has found a reproducer for the following issue on:

HEAD commit: ef6b35306dd8 Add linux-next specific files for 20220204
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1390be28700000
kernel config: https://syzkaller.appspot.com/x/.config?x=e0431e0b00810b4f
dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
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=133db2b4700000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17beb4a4700000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+afa2ca...@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x3d9c/0x54d0 kernel/locking/lockdep.c:4897
Read of size 8 at addr ffff88806dd607f8 by task syz-executor106/5085

CPU: 0 PID: 5085 Comm: syz-executor106 Not tainted 5.17.0-rc2-next-20220204-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
print_address_description.constprop.0.cold+0xa5/0x3e0 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
__lock_acquire+0x3d9c/0x54d0 kernel/locking/lockdep.c:4897
lock_acquire kernel/locking/lockdep.c:5639 [inline]
lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:354 [inline]
jbd2_journal_wait_updates+0x221/0x2b0 fs/jbd2/transaction.c:861
jbd2_journal_lock_updates+0x183/0x350 fs/jbd2/transaction.c:896
ext4_ioctl_checkpoint fs/ext4/ioctl.c:1085 [inline]
__ext4_ioctl+0x1fbb/0x5d10 fs/ext4/ioctl.c:1562
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
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:0x7fdf375bca89
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 81 15 00 00 90 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:00007ffeb1463618 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdf375bca89
RDX: 00000000200001c0 RSI: 000000004004662b RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007ffeb1463660 R09: 00007ffeb1463660
R10: 00007ffeb14630a0 R11: 0000000000000246 R12: 00007ffeb146364c
R13: 00007ffeb1463660 R14: 00007ffeb14636a0 R15: 00000000000000e5
</TASK>

Allocated by task 5083:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
__kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:469
kasan_slab_alloc include/linux/kasan.h:250 [inline]
slab_post_alloc_hook mm/slab.h:732 [inline]
slab_alloc_node mm/slub.c:3230 [inline]
slab_alloc mm/slub.c:3238 [inline]
kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3243
kmem_cache_zalloc include/linux/slab.h:705 [inline]
start_this_handle+0x66e/0x1380 fs/jbd2/transaction.c:375
jbd2__journal_start+0x399/0x930 fs/jbd2/transaction.c:525
__ext4_journal_start_sb+0x227/0x4a0 fs/ext4/ext4_jbd2.c:105
__ext4_new_inode+0x2d9e/0x56f0 fs/ext4/ialloc.c:1080
ext4_symlink+0x485/0xd40 fs/ext4/namei.c:3293
vfs_symlink fs/namei.c:4299 [inline]
vfs_symlink+0x108/0x2c0 fs/namei.c:4284
do_symlinkat+0x261/0x2e0 fs/namei.c:4328
__do_sys_symlink fs/namei.c:4350 [inline]
__se_sys_symlink fs/namei.c:4348 [inline]
__x64_sys_symlink+0x75/0x90 fs/namei.c:4348
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

Freed by task 5079:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0x166/0x1a0 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:226 [inline]
slab_free_hook mm/slub.c:1728 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1754
slab_free mm/slub.c:3509 [inline]
kmem_cache_free+0xdb/0x3b0 mm/slub.c:3526
jbd2_journal_free_transaction+0x30/0x40 fs/jbd2/transaction.c:62
__jbd2_journal_remove_checkpoint+0x438/0x840 fs/jbd2/checkpoint.c:735
jbd2_log_do_checkpoint+0x494/0xf70 fs/jbd2/checkpoint.c:354
jbd2_journal_flush+0x1a5/0xc70 fs/jbd2/journal.c:2465
ext4_ioctl_checkpoint fs/ext4/ioctl.c:1086 [inline]
__ext4_ioctl+0x200e/0x5d10 fs/ext4/ioctl.c:1562
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
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

The buggy address belongs to the object at ffff88806dd60780
which belongs to the cache jbd2_transaction_s of size 280
The buggy address is located 120 bytes inside of
280-byte region [ffff88806dd60780, ffff88806dd60898)
The buggy address belongs to the page:
page:ffffea0001b75800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x6dd60
head:ffffea0001b75800 order:1 compound_mapcount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffffea0001b75300 dead000000000002 ffff888017f083c0
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 3637, ts 427493856385, free_ts 14110756876
prep_new_page mm/page_alloc.c:2489 [inline]
get_page_from_freelist+0x13ea/0x31d0 mm/page_alloc.c:4219
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5435
alloc_pages+0x1aa/0x310 mm/mempolicy.c:2268
alloc_slab_page mm/slub.c:1799 [inline]
allocate_slab mm/slub.c:1944 [inline]
new_slab+0x295/0x400 mm/slub.c:2004
___slab_alloc+0x7ed/0xe00 mm/slub.c:3018
__slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3105
slab_alloc_node mm/slub.c:3196 [inline]
slab_alloc mm/slub.c:3238 [inline]
kmem_cache_alloc+0x35c/0x3a0 mm/slub.c:3243
kmem_cache_zalloc include/linux/slab.h:705 [inline]
start_this_handle+0x66e/0x1380 fs/jbd2/transaction.c:375
jbd2__journal_start+0x399/0x930 fs/jbd2/transaction.c:525
__ext4_journal_start_sb+0x227/0x4a0 fs/ext4/ext4_jbd2.c:105
__ext4_journal_start fs/ext4/ext4_jbd2.h:326 [inline]
ext4_dirty_inode+0x9d/0x110 fs/ext4/inode.c:5899
__mark_inode_dirty+0x45b/0xfe0 fs/fs-writeback.c:2370
generic_update_time fs/inode.c:1856 [inline]
inode_update_time fs/inode.c:1869 [inline]
touch_atime+0x63d/0x700 fs/inode.c:1941
file_accessed include/linux/fs.h:2422 [inline]
iterate_dir+0x465/0x700 fs/readdir.c:70
__do_sys_getdents64 fs/readdir.c:369 [inline]
__se_sys_getdents64 fs/readdir.c:354 [inline]
__x64_sys_getdents64+0x13a/0x2c0 fs/readdir.c:354
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/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:1356 [inline]
free_pcp_prepare+0x549/0xd20 mm/page_alloc.c:1406
free_unref_page_prepare mm/page_alloc.c:3376 [inline]
free_unref_page+0x19/0x6c0 mm/page_alloc.c:3455
free_contig_range+0xb1/0x180 mm/page_alloc.c:9434
destroy_args+0xa8/0x646 mm/debug_vm_pgtable.c:1018
debug_vm_pgtable+0x2a74/0x2b06 mm/debug_vm_pgtable.c:1332
do_one_initcall+0x103/0x650 init/main.c:1303
do_initcall_level init/main.c:1378 [inline]
do_initcalls init/main.c:1394 [inline]
do_basic_setup init/main.c:1413 [inline]
kernel_init_freeable+0x6b1/0x73a init/main.c:1618
kernel_init+0x1a/0x1d0 init/main.c:1507
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

Memory state around the buggy address:
ffff88806dd60680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88806dd60700: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88806dd60780: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88806dd60800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88806dd60880: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

Ritesh Harjani

unread,
Feb 9, 2022, 1:43:46 AM2/9/22
to syzbot, ja...@suse.com, ja...@suse.cz, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
On 22/02/08 08:19PM, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: ef6b35306dd8 Add linux-next specific files for 20220204
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1390be28700000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e0431e0b00810b4f
> dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
> 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=133db2b4700000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17beb4a4700000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+afa2ca...@syzkaller.appspotmail.com
>

#syz test: https://github.com/riteshharjani/linux.git jbd2-kill-t-handle-lock

syzbot

unread,
Feb 9, 2022, 1:56:08 AM2/9/22
to ja...@suse.com, ja...@suse.cz, linux...@vger.kernel.org, linux-...@vger.kernel.org, rit...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in jbd2_journal_wait_updates

==================================================================
BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:71 [inline]
BUG: KASAN: use-after-free in atomic_read include/linux/atomic/atomic-instrumented.h:27 [inline]
BUG: KASAN: use-after-free in jbd2_journal_wait_updates+0x110/0x270 fs/jbd2/transaction.c:842
Read of size 4 at addr ffff8880692a7ed0 by task syz-executor737/6052

CPU: 0 PID: 6052 Comm: syz-executor737 Not tainted 5.17.0-rc3-syzkaller-00031-g3ca14294b33a #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
print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
instrument_atomic_read include/linux/instrumented.h:71 [inline]
atomic_read include/linux/atomic/atomic-instrumented.h:27 [inline]
jbd2_journal_wait_updates+0x110/0x270 fs/jbd2/transaction.c:842
jbd2_journal_lock_updates+0x183/0x350 fs/jbd2/transaction.c:884
ext4_ioctl_checkpoint fs/ext4/ioctl.c:1085 [inline]
__ext4_ioctl+0x1fba/0x57e0 fs/ext4/ioctl.c:1562
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
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:0x7fd37940fa79
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 81 15 00 00 90 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:00007ffd07b8da78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fd37940fa79
RDX: 00000000200001c0 RSI: 000000004004662b RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007ffd07b8dac0 R09: 00007ffd07b8dac0
R10: 00007ffd07b8d500 R11: 0000000000000246 R12: 00007ffd07b8daac
R13: 00007ffd07b8dac0 R14: 00007ffd07b8db00 R15: 000000000000013e
</TASK>

Allocated by task 4066:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
__kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:469
kasan_slab_alloc include/linux/kasan.h:260 [inline]
slab_post_alloc_hook mm/slab.h:732 [inline]
slab_alloc_node mm/slub.c:3230 [inline]
slab_alloc mm/slub.c:3238 [inline]
kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3243
kmem_cache_zalloc include/linux/slab.h:705 [inline]
start_this_handle+0x674/0x14a0 fs/jbd2/transaction.c:370
jbd2__journal_start+0x399/0x930 fs/jbd2/transaction.c:520
__ext4_journal_start_sb+0x227/0x4a0 fs/ext4/ext4_jbd2.c:105
__ext4_journal_start fs/ext4/ext4_jbd2.h:326 [inline]
ext4_unlink+0x2f4/0x9e0 fs/ext4/namei.c:3224
vfs_unlink+0x351/0x920 fs/namei.c:4150
do_unlinkat+0x3c9/0x650 fs/namei.c:4218
__do_sys_unlink fs/namei.c:4266 [inline]
__se_sys_unlink fs/namei.c:4264 [inline]
__x64_sys_unlink+0xc6/0x110 fs/namei.c:4264
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

Freed by task 6049:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0x130/0x160 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:236 [inline]
slab_free_hook mm/slub.c:1728 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1754
slab_free mm/slub.c:3509 [inline]
kmem_cache_free+0xd8/0x340 mm/slub.c:3526
jbd2_journal_free_transaction+0x30/0x40 fs/jbd2/transaction.c:62
__jbd2_journal_remove_checkpoint+0x438/0x840 fs/jbd2/checkpoint.c:735
jbd2_log_do_checkpoint+0x49c/0xf80 fs/jbd2/checkpoint.c:354
jbd2_journal_flush+0x1a5/0xc70 fs/jbd2/journal.c:2465
ext4_ioctl_checkpoint fs/ext4/ioctl.c:1086 [inline]
__ext4_ioctl+0x200d/0x57e0 fs/ext4/ioctl.c:1562
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
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

The buggy address belongs to the object at ffff8880692a7e00
which belongs to the cache jbd2_transaction_s of size 280
The buggy address is located 208 bytes inside of
280-byte region [ffff8880692a7e00, ffff8880692a7f18)
The buggy address belongs to the page:
page:ffffea0001a4a980 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x692a6
head:ffffea0001a4a980 order:1 compound_mapcount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffffea0001a4c380 dead000000000002 ffff888017fe3a00
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 4065, ts 93350012176, free_ts 14405406818
prep_new_page mm/page_alloc.c:2434 [inline]
get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
alloc_pages+0x1aa/0x310 mm/mempolicy.c:2271
alloc_slab_page mm/slub.c:1799 [inline]
allocate_slab mm/slub.c:1944 [inline]
new_slab+0x28a/0x3b0 mm/slub.c:2004
___slab_alloc+0x87c/0xe90 mm/slub.c:3018
__slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3105
slab_alloc_node mm/slub.c:3196 [inline]
slab_alloc mm/slub.c:3238 [inline]
kmem_cache_alloc+0x35c/0x3a0 mm/slub.c:3243
kmem_cache_zalloc include/linux/slab.h:705 [inline]
start_this_handle+0x674/0x14a0 fs/jbd2/transaction.c:370
jbd2__journal_start+0x399/0x930 fs/jbd2/transaction.c:520
__ext4_journal_start_sb+0x227/0x4a0 fs/ext4/ext4_jbd2.c:105
__ext4_journal_start fs/ext4/ext4_jbd2.h:326 [inline]
ext4_dirty_inode+0x9d/0x110 fs/ext4/inode.c:5899
__mark_inode_dirty+0x45b/0xfe0 fs/fs-writeback.c:2409
generic_update_time fs/inode.c:1856 [inline]
inode_update_time fs/inode.c:1869 [inline]
touch_atime+0x63d/0x700 fs/inode.c:1941
file_accessed include/linux/fs.h:2421 [inline]
iterate_dir+0x465/0x700 fs/readdir.c:70
__do_sys_getdents64 fs/readdir.c:369 [inline]
__se_sys_getdents64 fs/readdir.c:354 [inline]
__x64_sys_getdents64+0x13a/0x2c0 fs/readdir.c:354
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/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:1352 [inline]
free_pcp_prepare+0x374/0x870 mm/page_alloc.c:1404
free_unref_page_prepare mm/page_alloc.c:3325 [inline]
free_unref_page+0x19/0x690 mm/page_alloc.c:3404
free_contig_range+0xa8/0xf0 mm/page_alloc.c:9335
destroy_args+0xa8/0x646 mm/debug_vm_pgtable.c:1018
debug_vm_pgtable+0x298e/0x2a20 mm/debug_vm_pgtable.c:1332
do_one_initcall+0x103/0x650 init/main.c:1300
do_initcall_level init/main.c:1373 [inline]
do_initcalls init/main.c:1389 [inline]
do_basic_setup init/main.c:1408 [inline]
kernel_init_freeable+0x6b1/0x73a init/main.c:1613
kernel_init+0x1a/0x1d0 init/main.c:1502
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

Memory state around the buggy address:
ffff8880692a7d80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880692a7e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880692a7e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880692a7f00: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880692a7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


Tested on:

commit: 3ca14294 jbd2: Remove CONFIG_JBD2_DEBUG to update t_ma..
git tree: https://github.com/riteshharjani/linux.git jbd2-kill-t-handle-lock
console output: https://syzkaller.appspot.com/x/log.txt?x=16b914a4700000
kernel config: https://syzkaller.appspot.com/x/.config?x=266de9da75c71a45

Ritesh Harjani

unread,
Feb 9, 2022, 2:41:46 AM2/9/22
to syzbot, ja...@suse.com, ja...@suse.cz, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
On 22/02/08 10:56PM, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> KASAN: use-after-free Read in jbd2_journal_wait_updates
>

#syz test: https://github.com/riteshharjani/linux.git jbd2-kill-t-handle-lock-t2

syzbot

unread,
Feb 9, 2022, 2:55:13 AM2/9/22
to ja...@suse.com, ja...@suse.cz, linux...@vger.kernel.org, linux-...@vger.kernel.org, rit...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+afa2ca...@syzkaller.appspotmail.com

Tested on:

commit: 54ccc072 jbd2: Remove CONFIG_JBD2_DEBUG to update t_ma..
git tree: https://github.com/riteshharjani/linux.git jbd2-kill-t-handle-lock-t2
kernel config: https://syzkaller.appspot.com/x/.config?x=266de9da75c71a45
dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Note: testing is done by a robot and is best-effort only.

Ritesh Harjani

unread,
Feb 9, 2022, 4:56:56 AM2/9/22
to Jan Kara, syzbot, ja...@suse.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
On 22/02/08 05:14PM, Jan Kara wrote:
> On Tue 08-02-22 04:49:19, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 555f3d7be91a Merge tag '5.17-rc3-ksmbd-server-fixes' of gi..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17e55852700000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=88e0a6a3dbf057cf
> > dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
> > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b03872700000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+afa2ca...@syzkaller.appspotmail.com
>
> So the syzbot reproducer looks bogus to me but the bug is real.
> jbd2_journal_wait_updates() looks at commit_transaction after dropping
> j_state_lock and sleeping which is certainly prone to use-after-free
> issues.

Yes, thanks for taking a look at it.

>
> Funnily, Ritesh's removal of t_handle_lock should "fix" the problem by
> removing this dereference. So Ritesh, please just add some reference to
> syzbot report and maybe a backport to stable would be warranted.
>

This actually looks like a regression because of commit [1].
So I am thinking of sending a separate patch [2] as a fix for this (after my
testing).

Not sure why fstests testing didn't pick this up (given it's a common race),
or is it because of my recent removal of CONFIG_KASAN from my testing :(

I will try a full "auto" test with CONFIG_KASAN enabled and see if we could hit
this in fstests or not. If not then I will work towards adding a targetted test
to capture such race.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=origin&id=4f98186848707f530669238d90e0562d92a78aab
[2]: https://github.com/riteshharjani/linux/commit/628648810011a22dfaba38ead49716720b27a31c

-ritesh

Jan Kara

unread,
Feb 9, 2022, 6:18:35 AM2/9/22
to Ritesh Harjani, Jan Kara, syzbot, ja...@suse.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Yeah, and my fault for not catching this during review :-|. Anyway the
proposed fix looks good.

> Not sure why fstests testing didn't pick this up (given it's a common race),
> or is it because of my recent removal of CONFIG_KASAN from my testing :(
>
> I will try a full "auto" test with CONFIG_KASAN enabled and see if we could hit
> this in fstests or not. If not then I will work towards adding a targetted test
> to capture such race.

Yeah, without KASAN this could lead to memory corruption by the spin_lock()
but in most cases it will just pass by unnoticed because the memory does
not get reused so quickly.

syzbot

unread,
Feb 10, 2022, 5:25:08 AM2/10/22
to rit...@linux.ibm.com, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+afa2ca...@syzkaller.appspotmail.com

Tested on:

commit: 948c2fed jbd2: Fix use-after-free of transaction_t race
git tree: https://github.com/riteshharjani/linux.git jbd2-kill-t-handle-lock-t3
kernel config: https://syzkaller.appspot.com/x/.config?x=266de9da75c71a45
dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348

Ritesh Harjani

unread,
Feb 10, 2022, 10:57:14 AM2/10/22
to Jan Kara, syzbot, ja...@suse.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
FWIW, I did try "auto" run with CONFIG_KASAN enabled (which took hell lot of
a time to complete :-|) w/o the fix. But it didn't hit this race.

Then, I also tried below combination of dirtying some data and calling
checkpoint_journal in seperate thread, but I wasn't able to hit this race.
(Using checkpoint_journal since it will call for jbd2_journal_lock_updates())

sudo mount /dev/loop2 /mnt

Terminal-1 # Tried other combination of higher D, n & S0/1/2, s0/100/4096
===========
qemu-> echo /mnt/{1..32} |sed -E 's/[[:space:]]+/ -d /g' | xargs -I {} bash -c "sudo fs_mark -L 100000 -D 4 -n 4 -s 100 -S0 -d {}"

Terminal-2
=============
qemu-> while [ 1 ]; do sudo ./src/checkpoint_journal /mnt; sleep 5; done

Also, I did made other failed attempts with some combinations of running fs_mark with freeze/unfreeze
(similar to checkpoint_journal), and also changing "commit=1" mount option to
see if we could hit the race with some such combo.

So if anyone else has any suggestions on what else can we try to hit this race,
so that we can add such test case to fstests, I will be happy to attempt it.

-ritesh
Reply all
Reply to author
Forward
0 new messages