On Wed, Jun 3, 2026 at 8:38 AM Aleksandr Nogikh <[email protected]> wrote: > > On Wed, Jun 3, 2026 at 3:34 AM 'Masami Hiramatsu' via syzkaller-bugs > <[email protected]> wrote: > > > > On Tue, 2 Jun 2026 12:28:29 -0400 > > Steven Rostedt <[email protected]> wrote: > > > > > On Tue, 02 Jun 2026 06:45:31 -0700 > > > syzbot <[email protected]> wrote: > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit: e7ae89a0c97c Linux 7.1-rc5 > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16f06e2e580000 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=58acee1ac5406016 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=2dd9d02f60775ce5c1fb > > > > compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for > > > > Debian) 2.44 > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > Looks like the test was doing something really weird to trigger this. > > > Without a reproducer, it's pretty much impossible to find out what > > > happened. Maybe AI could do it? > > > > > > > Does the "I don't have any reproducer for this issue yet." means > > this is not reproducible even if it runs completely same sequence > > in the console output? If so, might this be a timing related issue? > > (e.g. read v.s. write-event) > > Yes, syzbot normally re-plays the sequence of last programs executed > on the crashed VM to find a reproducer, and, in many cases, they no > longer crash the kernel.. > > In the meanwhile, syzbot's AI bug reproduction functionality has found > a C reproducer for a KASAN crash in the kernel/trace's ring buffer, > although with a slightly different stack trace: > https://syzkaller.appspot.com/ai_job?id=b2620161-1632-4d4e-9314-114a8a5e79ef > > Cc Alexander Potapenko
Yes, the bug that the AI reproduced manifests with a different stack: BUG: KASAN: slab-use-after-free in instrument_copy_to_user include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-use-after-free in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-use-after-free in _copy_to_user+0x79/0xb0 lib/usercopy.c:26 Read of size 12288 at addr ffff888180423000 by task syz-executor144/5941 CPU: 1 UID: 0 PID: 5941 Comm: syz-executor144 Not tainted syzkaller #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 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 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200 instrument_copy_to_user include/linux/instrumented.h:129 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0x79/0xb0 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] tracing_buffers_read+0x4cd/0xd60 kernel/trace/trace.c:7158 vfs_read+0x20c/0xa70 fs/read_write.c:572 ksys_read+0x150/0x270 fs/read_write.c:717 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f9facd00cde Code: 08 0f 85 f5 e2 ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 90 41 57 41 56 4d 89 c6 41 55 4d 89 cd 41 54 55 53 48 83 ec 08 RSP: 002b:00007f9fabc9e198 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f9fabca26c0 RCX: 00007f9facd00cde RDX: 0000000000004000 RSI: 00007f9fabc9e200 RDI: 0000000000000006 RBP: 00007f9fabc9e200 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9facd7ab20 R13: 0000000000000000 R14: 00007ffd6ed73110 R15: 00007ffd6ed731f8 </TASK> Quoting the AI itself: """ The reproducer successfully triggered a KASAN use-after-free crash in the tracing subsystem. Although the exact crash signature differs slightly (a read in `_copy_to_user` called from `tracing_buffers_read` vs a write in `ring_buffer_read_page` called from `tracing_buffers_read`), both crashes are use-after-free bugs on ring buffer pages accessed during `tracing_buffers_read`. The reproduced crash shows the page being freed by `ring_buffer_subbuf_order_set` (via `buffer_subbuf_size_write`) while being concurrently accessed by `tracing_buffers_read`. This confirms the underlying race condition between reading the trace buffers and modifying the buffer size/order has been successfully reproduced. """ I took a glance at the reports, and the above makes sense: we just happen to access filp->private_data->spare at different times after it has been freed. PS. Please bear with repro-c, it's making its baby steps. The reproducer contains some dead code, and the results are hard to navigate. At some point we'll probably be able to link AI-generated repros from the original bugs.
