Dear Maintainers, When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash was triggered. Kernel commit: v6.14-rc4 (Commits on Feb 24, 2025) Kernel Config : https://github.com/Strforexc/LinuxKernelbug/blob/main/.config Kernel Log: attachment I’ve encountered a KASAN-reported global-out-of-bounds read in Linux kernel 6.14.0-rc4, involving the RCU subsystem and bcachefs. Here are the details: A global-out-of-bounds read of size 1 was detected at address ffffffff8b8e8d55 in string_nocheck (lib/vsprintf.c:632), called from string (lib/vsprintf.c:714). The buggy address belongs to str__rcu__trace_system_name+0x815/0xb40, triggered by a kworker task. The issue occurs during a bcachefs transaction commit (bch2_trans_commit), which enqueues an RCU callback via srcu_gp_start_if_needed. The out-of-bounds access happens in string_nocheck, likely during a printk or tracepoint operation (vprintk_emit), triggered by a lockdep warning (__warn_printk). The variable str__rcu__trace_system_name (size 0xb40) is overrun at offset 0x815, suggesting a string handling bug in RCU or bcachefs debug output. The bug was observed in a QEMU environment during btree_interior_update_work execution in bcachefs. It may involve filesystem operations (e.g., key cache dropping) under load. I don’t have a precise reproducer yet but can assist with testing. Could RCU or bcachefs maintainers investigate? This might be a tracepoint or printk format string issue in srcu_gp_start_if_needed or related code. I suspect an invalid index into str__rcu__trace_system_name or a pointer corruption. Happy to provide more logs or test patches. If you fix this issue, please add the following tag to the commit: Reported-by: Zhizhuo Tang <strforexctzzchange@xxxxxxxxxxx>, Jianzhou Zhao <xnxc22xnxc22@xxxxxx>, Haoran Liu <cherest_san@xxxxxxx> ------------[ cut here ]------------ ================================================================== BUG: KASAN: global-out-of-bounds in string_nocheck lib/vsprintf.c:632 [inline] BUG: KASAN: global-out-of-bounds in string+0x4b3/0x500 lib/vsprintf.c:714 Read of size 1 at addr ffffffff8b8e8d55 by task kworker/u10:0/28 CPU: 1 UID: 0 PID: 28 Comm: kworker/u10:0 Not tainted 6.14.0-rc4 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: btree_update btree_interior_update_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description.constprop.0+0x2c/0x420 mm/kasan/report.c:408 print_report+0xaa/0x270 mm/kasan/report.c:521 kasan_report+0xbd/0x100 mm/kasan/report.c:634 string_nocheck lib/vsprintf.c:632 [inline] string+0x4b3/0x500 lib/vsprintf.c:714 vsnprintf+0x620/0x1120 lib/vsprintf.c:2843 vprintk_store+0x34f/0xb90 kernel/printk/printk.c:2279 vprintk_emit+0x151/0x330 kernel/printk/printk.c:2408 __warn_printk+0x162/0x320 kernel/panic.c:797 look_up_lock_class+0xad/0x160 kernel/locking/lockdep.c:938 register_lock_class+0xb2/0xfc0 kernel/locking/lockdep.c:1292 __lock_acquire+0xc3/0x16a0 kernel/locking/lockdep.c:5103 lock_acquire+0x181/0x3a0 kernel/locking/lockdep.c:5851 __raw_spin_trylock include/linux/spinlock_api_smp.h:90 [inline] _raw_spin_trylock+0x76/0xa0 kernel/locking/spinlock.c:138 spin_lock_irqsave_sdp_contention kernel/rcu/srcutree.c:375 [inline] srcu_gp_start_if_needed+0x1a9/0x5f0 kernel/rcu/srcutree.c:1270 __call_rcu fs/bcachefs/rcu_pending.c:76 [inline] __rcu_pending_enqueue fs/bcachefs/rcu_pending.c:497 [inline] rcu_pending_enqueue+0x686/0xd30 fs/bcachefs/rcu_pending.c:531 bkey_cached_free+0xfd/0x170 fs/bcachefs/btree_key_cache.c:115 bch2_btree_key_cache_drop+0xe7/0x770 fs/bcachefs/btree_key_cache.c:613 bch2_trans_commit_write_locked.constprop.0+0x2bc6/0x3bc0 fs/bcachefs/btree_trans_commit.c:794 do_bch2_trans_commit.isra.0+0x7a6/0x12f0 fs/bcachefs/btree_trans_commit.c:866 __bch2_trans_commit+0x1018/0x18e0 fs/bcachefs/btree_trans_commit.c:1070 bch2_trans_commit fs/bcachefs/btree_update.h:183 [inline] btree_update_nodes_written+0x1352/0x2210 fs/bcachefs/btree_update_interior.c:708 btree_interior_update_work+0xda/0x100 fs/bcachefs/btree_update_interior.c:846 process_one_work+0x109d/0x18c0 kernel/workqueue.c:3236 process_scheduled_works kernel/workqueue.c:3317 [inline] worker_thread+0x677/0xe90 kernel/workqueue.c:3398 kthread+0x3b3/0x760 kernel/kthread.c:464 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> The buggy address belongs to the variable: str__rcu__trace_system_name+0x815/0xb40 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb8e8 flags: 0xfff00000002000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000002000 ffffea00002e3a08 ffffea00002e3a08 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b8e8c00: f9 f9 f9 f9 00 00 00 00 03 f9 f9 f9 f9 f9 f9 f9 ffffffff8b8e8c80: 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 00 00 00 07 >ffffffff8b8e8d00: f9 f9 f9 f9 00 00 00 03 f9 f9 f9 f9 00 00 00 06 ^ ffffffff8b8e8d80: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 01 f9 ffffffff8b8e8e00: f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 00 00 00 00 ================================================================== Thanks, Zhizhuo Tang
Attachment:
log
Description: Binary data
