* [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree
@ 2026-06-17 17:08 syzbot
2026-06-18 18:44 ` rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] Jann Horn
0 siblings, 1 reply; 5+ messages in thread
From: syzbot @ 2026-06-17 17:08 UTC (permalink / raw)
To: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro
Hello,
syzbot found the following issue on:
HEAD commit: c425609d6ac4 Add linux-next specific files for 20260612
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12864986580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d7a56b1e89b63439
dashboard link: https://syzkaller.appspot.com/bug?extid=000c800a02097aaa10ed
compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/7fab9a8df61a/disk-c425609d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c2577196651b/vmlinux-c425609d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/053557a7471e/bzImage-c425609d.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+000c800a02097aaa10ed@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166
Read of size 1 at addr ffff8880400e5570 by task syz-executor/5618
CPU: 0 UID: 0 PID: 5618 Comm: syz-executor Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
__kasan_check_byte+0x2a/0x40 mm/kasan/common.c:574
kasan_check_byte include/linux/kasan.h:402 [inline]
lock_acquire+0x84/0x350 kernel/locking/lockdep.c:5844
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166
rt_mutex_slowunlock+0xbf/0xa20 kernel/locking/rtmutex.c:1430
spin_unlock include/linux/spinlock_rt.h:109 [inline]
shrink_dcache_tree+0x30e/0x410 fs/dcache.c:1754
vfs_rmdir+0x425/0x6b0 fs/namei.c:5381
filename_rmdir+0x292/0x520 fs/namei.c:5434
__do_sys_unlinkat fs/namei.c:5609 [inline]
__se_sys_unlinkat+0x71/0x1a0 fs/namei.c:5602
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe005bdbf77
Code: 77 01 c3 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 07 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffef7890fe8 EFLAGS: 00000207 ORIG_RAX: 0000000000000107
RAX: ffffffffffffffda RBX: 0000000000000065 RCX: 00007fe005bdbf77
RDX: 0000000000000200 RSI: 00007ffef7892130 RDI: 00000000ffffff9c
RBP: 00007fe005c721ca R08: 00000000000065c0 R09: 00000000ffffffff
R10: 0000000000000100 R11: 0000000000000207 R12: 00007ffef7892130
R13: 00007fe005c721ca R14: 0000000000022281 R15: 00007ffef7892170
</TASK>
Allocated by task 6103:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4610 [inline]
slab_alloc_node mm/slub.c:4943 [inline]
kmem_cache_alloc_lru_noprof+0x347/0x6a0 mm/slub.c:4976
__d_alloc+0x37/0x6f0 fs/dcache.c:1902
d_alloc_parallel+0xde/0x16c0 fs/dcache.c:2761
lookup_open fs/namei.c:4423 [inline]
open_last_lookups fs/namei.c:4608 [inline]
path_openat+0xbf0/0x3850 fs/namei.c:4856
do_file_open+0x23e/0x4a0 fs/namei.c:4888
do_sys_openat2+0x115/0x200 fs/open.c:1368
do_sys_open fs/open.c:1374 [inline]
__do_sys_openat fs/open.c:1390 [inline]
__se_sys_openat fs/open.c:1385 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1385
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 29:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2703 [inline]
slab_free mm/slub.c:6402 [inline]
kmem_cache_free+0x187/0x6c0 mm/slub.c:6529
rcu_do_batch kernel/rcu/tree.c:2645 [inline]
rcu_core kernel/rcu/tree.c:2897 [inline]
rcu_cpu_kthread+0x950/0x1480 kernel/rcu/tree.c:2985
smpboot_thread_fn+0x57c/0xa80 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
__call_rcu_common kernel/rcu/tree.c:3159 [inline]
call_rcu+0xee/0x8b0 kernel/rcu/tree.c:3279
dentry_kill+0x4d3/0x880 fs/dcache.c:845
finish_dput+0x1a/0x260 fs/dcache.c:1001
__fput+0x699/0xa80 fs/file_table.c:520
task_work_run+0x1d9/0x270 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:70 [inline]
exit_to_user_mode_loop+0x1fa/0x730 kernel/entry/common.c:101
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x353/0x580 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8880400e54a0
which belongs to the cache dentry of size 376
The buggy address is located 208 bytes inside of
freed 376-byte region [ffff8880400e54a0, ffff8880400e5618)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x400e4
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888031f5da01
flags: 0x80000000000040(head|node=0|zone=1)
page_type: f5(slab)
raw: 0080000000000040 ffff88801be88500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800120012 00000000f5000000 ffff888031f5da01
head: 0080000000000040 ffff88801be88500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800120012 00000000f5000000 ffff888031f5da01
head: 0080000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000002
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Reclaimable, gfp_mask 0xd20d0(__GFP_RECLAIMABLE|__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 4988, tgid 4988 (udevd), ts 46901016481, free_ts 0
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1859
prep_new_page mm/page_alloc.c:1867 [inline]
get_page_from_freelist+0x2639/0x26b0 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5304
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x79/0x5e0 mm/slub.c:3406
new_slab mm/slub.c:3452 [inline]
refill_objects+0x2d8/0x350 mm/slub.c:7335
refill_sheaf mm/slub.c:2830 [inline]
__pcs_replace_empty_main+0x330/0x690 mm/slub.c:4701
alloc_from_pcs mm/slub.c:4799 [inline]
slab_alloc_node mm/slub.c:4931 [inline]
kmem_cache_alloc_lru_noprof+0x45e/0x6a0 mm/slub.c:4976
__d_alloc+0x37/0x6f0 fs/dcache.c:1902
d_alloc+0x4b/0x190 fs/dcache.c:1981
lookup_one_qstr_excl+0xd8/0x360 fs/namei.c:1806
__start_dirop fs/namei.c:2920 [inline]
start_dirop fs/namei.c:2942 [inline]
filename_create+0x20e/0x370 fs/namei.c:4951
filename_symlinkat+0xf7/0x420 fs/namei.c:5675
__do_sys_symlink fs/namei.c:5708 [inline]
__se_sys_symlink+0x4d/0x2b0 fs/namei.c:5704
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page_owner free stack trace missing
Memory state around the buggy address:
ffff8880400e5400: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
ffff8880400e5480: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb
>ffff8880400e5500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880400e5580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880400e5600: fb fb fb fc fc fc fc fc fc fc fc 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.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 5+ messages in thread* rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] 2026-06-17 17:08 [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree syzbot @ 2026-06-18 18:44 ` Jann Horn 2026-06-18 20:59 ` Al Viro 0 siblings, 1 reply; 5+ messages in thread From: Jann Horn @ 2026-06-18 18:44 UTC (permalink / raw) To: Thomas Gleixner, Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt Cc: syzbot, Christian Brauner, Jan Kara, linux-fsdevel, kernel list, syzkaller-bugs, Al Viro I think this is more of a bug in RT spinlocks than a VFS bug, though it's a bit murky. rt_spin_unlock() looks like this: void __sched rt_spin_unlock(spinlock_t *lock) __releases(RCU) { spin_release(&lock->dep_map, _RET_IP_); migrate_enable(); rcu_read_unlock(); if (unlikely(!rt_mutex_cmpxchg_release(&lock->lock, current, NULL))) rt_mutex_slowunlock(&lock->lock); } Note how the RCU read-side critical section and the protection against migration end *before* the lock is actually released, which means this can UAF if the RCU read-side critical section implied by the spinlock is the only thing keeping the lock alive. While non-RT spinlocks do this the other way around (do_raw_spin_unlock() before preempt_enable()): static inline void __raw_spin_unlock(raw_spinlock_t *lock) __releases(lock) { spin_release(&lock->dep_map, _RET_IP_); do_raw_spin_unlock(lock); preempt_enable(); } https://docs.kernel.org/next/RCU/whatisRCU.html guarantees that spinlock APIs imply RCU, and https://docs.kernel.org/locking/mutex-design.html says: "This is in contrast with spin_unlock() [...], which APIs can be used to guarantee that the memory is not touched by the lock implementation after spin_unlock()/completion_done() releases the lock.". Neither of these explicitly guarantees that the RCU read-side critical section (and the protection against migration?) should still hold while the lock is being dropped, but I think that would fit best with the explicit guarantees? On Wed, Jun 17, 2026 at 7:08 PM syzbot <syzbot+000c800a02097aaa10ed@syzkaller.appspotmail.com> wrote: > syzbot found the following issue on: > > HEAD commit: c425609d6ac4 Add linux-next specific files for 20260612 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12864986580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=d7a56b1e89b63439 > dashboard link: https://syzkaller.appspot.com/bug?extid=000c800a02097aaa10ed > compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/7fab9a8df61a/disk-c425609d.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/c2577196651b/vmlinux-c425609d.xz > kernel image: https://storage.googleapis.com/syzbot-assets/053557a7471e/bzImage-c425609d.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+000c800a02097aaa10ed@syzkaller.appspotmail.com > > ================================================================== > BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline] > BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166 > Read of size 1 at addr ffff8880400e5570 by task syz-executor/5618 > > CPU: 0 UID: 0 PID: 5618 Comm: syz-executor Not tainted syzkaller #0 PREEMPT_{RT,(full)} > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 > Call Trace: > <TASK> > dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 > print_address_description+0x55/0x1e0 mm/kasan/report.c:378 > print_report+0x58/0x70 mm/kasan/report.c:482 > kasan_report+0x117/0x150 mm/kasan/report.c:595 > __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:574 > kasan_check_byte include/linux/kasan.h:402 [inline] > lock_acquire+0x84/0x350 kernel/locking/lockdep.c:5844 > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline] > _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166 > rt_mutex_slowunlock+0xbf/0xa20 kernel/locking/rtmutex.c:1430 > spin_unlock include/linux/spinlock_rt.h:109 [inline] > shrink_dcache_tree+0x30e/0x410 fs/dcache.c:1754 > vfs_rmdir+0x425/0x6b0 fs/namei.c:5381 > filename_rmdir+0x292/0x520 fs/namei.c:5434 > __do_sys_unlinkat fs/namei.c:5609 [inline] > __se_sys_unlinkat+0x71/0x1a0 fs/namei.c:5602 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7fe005bdbf77 > Code: 77 01 c3 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 07 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007ffef7890fe8 EFLAGS: 00000207 ORIG_RAX: 0000000000000107 > RAX: ffffffffffffffda RBX: 0000000000000065 RCX: 00007fe005bdbf77 > RDX: 0000000000000200 RSI: 00007ffef7892130 RDI: 00000000ffffff9c > RBP: 00007fe005c721ca R08: 00000000000065c0 R09: 00000000ffffffff > R10: 0000000000000100 R11: 0000000000000207 R12: 00007ffef7892130 > R13: 00007fe005c721ca R14: 0000000000022281 R15: 00007ffef7892170 > </TASK> > > Allocated by task 6103: > kasan_save_stack mm/kasan/common.c:57 [inline] > kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 > unpoison_slab_object mm/kasan/common.c:340 [inline] > __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 > kasan_slab_alloc include/linux/kasan.h:253 [inline] > slab_post_alloc_hook mm/slub.c:4610 [inline] > slab_alloc_node mm/slub.c:4943 [inline] > kmem_cache_alloc_lru_noprof+0x347/0x6a0 mm/slub.c:4976 > __d_alloc+0x37/0x6f0 fs/dcache.c:1902 > d_alloc_parallel+0xde/0x16c0 fs/dcache.c:2761 > lookup_open fs/namei.c:4423 [inline] > open_last_lookups fs/namei.c:4608 [inline] > path_openat+0xbf0/0x3850 fs/namei.c:4856 > do_file_open+0x23e/0x4a0 fs/namei.c:4888 > do_sys_openat2+0x115/0x200 fs/open.c:1368 > do_sys_open fs/open.c:1374 [inline] > __do_sys_openat fs/open.c:1390 [inline] > __se_sys_openat fs/open.c:1385 [inline] > __x64_sys_openat+0x138/0x170 fs/open.c:1385 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > Freed by task 29: > kasan_save_stack mm/kasan/common.c:57 [inline] > kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 > kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584 > poison_slab_object mm/kasan/common.c:253 [inline] > __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 > kasan_slab_free include/linux/kasan.h:235 [inline] > slab_free_hook mm/slub.c:2703 [inline] > slab_free mm/slub.c:6402 [inline] > kmem_cache_free+0x187/0x6c0 mm/slub.c:6529 > rcu_do_batch kernel/rcu/tree.c:2645 [inline] > rcu_core kernel/rcu/tree.c:2897 [inline] > rcu_cpu_kthread+0x950/0x1480 kernel/rcu/tree.c:2985 > smpboot_thread_fn+0x57c/0xa80 kernel/smpboot.c:160 > kthread+0x388/0x470 kernel/kthread.c:436 > ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 > ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 > > Last potentially related work creation: > kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57 > kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556 > __call_rcu_common kernel/rcu/tree.c:3159 [inline] > call_rcu+0xee/0x8b0 kernel/rcu/tree.c:3279 > dentry_kill+0x4d3/0x880 fs/dcache.c:845 > finish_dput+0x1a/0x260 fs/dcache.c:1001 > __fput+0x699/0xa80 fs/file_table.c:520 > task_work_run+0x1d9/0x270 kernel/task_work.c:233 > resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] > __exit_to_user_mode_loop kernel/entry/common.c:70 [inline] > exit_to_user_mode_loop+0x1fa/0x730 kernel/entry/common.c:101 > __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline] > syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline] > syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline] > do_syscall_64+0x353/0x580 arch/x86/entry/syscall_64.c:100 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > The buggy address belongs to the object at ffff8880400e54a0 > which belongs to the cache dentry of size 376 > The buggy address is located 208 bytes inside of > freed 376-byte region [ffff8880400e54a0, ffff8880400e5618) > > The buggy address belongs to the physical page: > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x400e4 > head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 > memcg:ffff888031f5da01 > flags: 0x80000000000040(head|node=0|zone=1) > page_type: f5(slab) > raw: 0080000000000040 ffff88801be88500 dead000000000100 dead000000000122 > raw: 0000000000000000 0000000800120012 00000000f5000000 ffff888031f5da01 > head: 0080000000000040 ffff88801be88500 dead000000000100 dead000000000122 > head: 0000000000000000 0000000800120012 00000000f5000000 ffff888031f5da01 > head: 0080000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff > head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000002 > page dumped because: kasan: bad access detected > page_owner tracks the page as allocated > page last allocated via order 1, migratetype Reclaimable, gfp_mask 0xd20d0(__GFP_RECLAIMABLE|__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 4988, tgid 4988 (udevd), ts 46901016481, free_ts 0 > set_page_owner include/linux/page_owner.h:32 [inline] > post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1859 > prep_new_page mm/page_alloc.c:1867 [inline] > get_page_from_freelist+0x2639/0x26b0 mm/page_alloc.c:3946 > __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5304 > alloc_slab_page mm/slub.c:3292 [inline] > allocate_slab+0x79/0x5e0 mm/slub.c:3406 > new_slab mm/slub.c:3452 [inline] > refill_objects+0x2d8/0x350 mm/slub.c:7335 > refill_sheaf mm/slub.c:2830 [inline] > __pcs_replace_empty_main+0x330/0x690 mm/slub.c:4701 > alloc_from_pcs mm/slub.c:4799 [inline] > slab_alloc_node mm/slub.c:4931 [inline] > kmem_cache_alloc_lru_noprof+0x45e/0x6a0 mm/slub.c:4976 > __d_alloc+0x37/0x6f0 fs/dcache.c:1902 > d_alloc+0x4b/0x190 fs/dcache.c:1981 > lookup_one_qstr_excl+0xd8/0x360 fs/namei.c:1806 > __start_dirop fs/namei.c:2920 [inline] > start_dirop fs/namei.c:2942 [inline] > filename_create+0x20e/0x370 fs/namei.c:4951 > filename_symlinkat+0xf7/0x420 fs/namei.c:5675 > __do_sys_symlink fs/namei.c:5708 [inline] > __se_sys_symlink+0x4d/0x2b0 fs/namei.c:5704 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > page_owner free stack trace missing > > Memory state around the buggy address: > ffff8880400e5400: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc > ffff8880400e5480: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb > >ffff8880400e5500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff8880400e5580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff8880400e5600: fb fb fb fc fc fc fc fc fc fc fc 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. > > If the report is already addressed, let syzbot know by replying with: > #syz fix: exact-commit-title > > If you want to overwrite report's subsystems, reply with: > #syz set subsystems: new-subsystem > (See the list of subsystem names on the web dashboard) > > If the report is a duplicate of another one, reply with: > #syz dup: exact-subject-of-another-report > > If you want to undo deduplication, reply with: > #syz undup ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] 2026-06-18 18:44 ` rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] Jann Horn @ 2026-06-18 20:59 ` Al Viro 2026-06-18 21:03 ` Al Viro 0 siblings, 1 reply; 5+ messages in thread From: Al Viro @ 2026-06-18 20:59 UTC (permalink / raw) To: Jann Horn Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, syzbot, Christian Brauner, Jan Kara, linux-fsdevel, kernel list, syzkaller-bugs, Jeff Layton On Thu, Jun 18, 2026 at 08:44:32PM +0200, Jann Horn wrote: > I think this is more of a bug in RT spinlocks than a VFS bug, though > it's a bit murky. > > rt_spin_unlock() looks like this: > > void __sched rt_spin_unlock(spinlock_t *lock) __releases(RCU) > { > spin_release(&lock->dep_map, _RET_IP_); > migrate_enable(); > rcu_read_unlock(); > > if (unlikely(!rt_mutex_cmpxchg_release(&lock->lock, current, NULL))) > rt_mutex_slowunlock(&lock->lock); > } > > Note how the RCU read-side critical section and the protection against > migration end *before* the lock is actually released, which means this > can UAF if the RCU read-side critical section implied by the spinlock > is the only thing keeping the lock alive. While non-RT spinlocks do > this the other way around (do_raw_spin_unlock() before > preempt_enable()): > > static inline void __raw_spin_unlock(raw_spinlock_t *lock) > __releases(lock) > { > spin_release(&lock->dep_map, _RET_IP_); > do_raw_spin_unlock(lock); > preempt_enable(); > } > > https://docs.kernel.org/next/RCU/whatisRCU.html guarantees that > spinlock APIs imply RCU, and > https://docs.kernel.org/locking/mutex-design.html says: "This is in > contrast with spin_unlock() [...], which APIs can be used to guarantee > that the memory is not touched by the lock implementation after > spin_unlock()/completion_done() releases the lock.". > Neither of these explicitly guarantees that the RCU read-side critical > section (and the protection against migration?) should still hold > while the lock is being dropped, but I think that would fit best with > the explicit guarantees? I'm trying to recall if PREEMPT_RT had been enabled in the last round of UAF in that area back in early April... As far as I'm concerned, we *do* need to keep RCU read-side critical area all the way until the end of spin_unlock(); it very well might be the only thing to prevent freeing the sucker under us. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] 2026-06-18 20:59 ` Al Viro @ 2026-06-18 21:03 ` Al Viro 2026-06-18 22:24 ` Thomas Gleixner 0 siblings, 1 reply; 5+ messages in thread From: Al Viro @ 2026-06-18 21:03 UTC (permalink / raw) To: Jann Horn Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, syzbot, Christian Brauner, Jan Kara, linux-fsdevel, kernel list, syzkaller-bugs, Jeff Layton On Thu, Jun 18, 2026 at 09:59:53PM +0100, Al Viro wrote: > > https://docs.kernel.org/next/RCU/whatisRCU.html guarantees that > > spinlock APIs imply RCU, and > > https://docs.kernel.org/locking/mutex-design.html says: "This is in > > contrast with spin_unlock() [...], which APIs can be used to guarantee > > that the memory is not touched by the lock implementation after > > spin_unlock()/completion_done() releases the lock.". > > Neither of these explicitly guarantees that the RCU read-side critical > > section (and the protection against migration?) should still hold > > while the lock is being dropped, but I think that would fit best with > > the explicit guarantees? > > I'm trying to recall if PREEMPT_RT had been enabled in the last round of > UAF in that area back in early April... > > As far as I'm concerned, we *do* need to keep RCU read-side critical area > all the way until the end of spin_unlock(); it very well might be the > only thing to prevent freeing the sucker under us. FWIW, https://lore.kernel.org/all/6a3094e7.428ffe26.258b27.0171.GAE@google.com/ looks potentially related... ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] 2026-06-18 21:03 ` Al Viro @ 2026-06-18 22:24 ` Thomas Gleixner 0 siblings, 0 replies; 5+ messages in thread From: Thomas Gleixner @ 2026-06-18 22:24 UTC (permalink / raw) To: Al Viro, Jann Horn Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt, syzbot, Christian Brauner, Jan Kara, linux-fsdevel, kernel list, syzkaller-bugs, Jeff Layton On Thu, Jun 18 2026 at 22:03, Al Viro wrote: > On Thu, Jun 18, 2026 at 09:59:53PM +0100, Al Viro wrote: >> > https://docs.kernel.org/next/RCU/whatisRCU.html guarantees that >> > spinlock APIs imply RCU, and >> > https://docs.kernel.org/locking/mutex-design.html says: "This is in >> > contrast with spin_unlock() [...], which APIs can be used to guarantee >> > that the memory is not touched by the lock implementation after >> > spin_unlock()/completion_done() releases the lock.". >> > Neither of these explicitly guarantees that the RCU read-side critical >> > section (and the protection against migration?) should still hold >> > while the lock is being dropped, but I think that would fit best with >> > the explicit guarantees? >> >> I'm trying to recall if PREEMPT_RT had been enabled in the last round of >> UAF in that area back in early April... >> >> As far as I'm concerned, we *do* need to keep RCU read-side critical area >> all the way until the end of spin_unlock(); it very well might be the >> only thing to prevent freeing the sucker under us. Right. That's clearly a bug in rt_spin_unlock(). I think I wrote it that way for symmetry vs. lock(), which is obviously wrong. Fix below. Thanks, tglx --- Subject: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() From: Thomas Gleixner <tglx@kernel.org> Date: Thu, 18 Jun 2026 23:32:43 +0200 rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1 T2 spin_lock(&p->lock); rcu_read_lock(); invalidate(p); p = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL); if (!p) return; // Not taken spin_unlock(&p->lock); spin_lock(&p->lock) lock(&lock->lock); rcu_read_lock(); kfree_rcu(p); rcu_read_unlock(); .... spin_unlock(&p->lock) rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); UAF -> rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Move the rcu_read_unlock() invocation past the unlock operation to match the non-RT semantics and add a comment explaining why rcu_read_unlock() must come last. This makes it asymmetric vs. rt_spin_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled. Fixes: 0f383b6dc96e ("locking/spinlock: Provide RT variant") Reported-by: syzbot+000c800a02097aaa10ed@syzkaller.appspotmail.com Decoded-by: Jann Horn <jannh@google.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org --- kernel/locking/spinlock_rt.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) --- a/kernel/locking/spinlock_rt.c +++ b/kernel/locking/spinlock_rt.c @@ -79,10 +79,27 @@ void __sched rt_spin_unlock(spinlock_t * { spin_release(&lock->dep_map, _RET_IP_); migrate_enable(); - rcu_read_unlock(); if (unlikely(!rt_mutex_cmpxchg_release(&lock->lock, current, NULL))) rt_mutex_slowunlock(&lock->lock); + + /* + * This must be last to prevent the following UAF: + * + * T1 T2 + * spin_lock(&p->lock); rcu_read_lock(); + * invalidate(p); p = rcu_dereference(ptr); + * rcu_assign_pointer(ptr, NULL); if (!p) return; + * spin_unlock(&p->lock); spin_lock(&p->lock); + * kfree_rcu(p); rcu_read_unlock(); + * .... + * spin_unlock(&p->lock) + * rcu_read_unlock(); // Ends grace period + * rcu_do_batch() + * kfree(p); + * UAF -> rt_mutex_cmpxchg_release(&p->lock.lock...) + */ + rcu_read_unlock(); } EXPORT_SYMBOL(rt_spin_unlock); ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-06-18 22:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-06-17 17:08 [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree syzbot 2026-06-18 18:44 ` rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree] Jann Horn 2026-06-18 20:59 ` Al Viro 2026-06-18 21:03 ` Al Viro 2026-06-18 22:24 ` Thomas Gleixner
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.