CVE-2025-38267

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Do not trigger WARN_ON() due to a commit_overrun<br /> <br /> When reading a memory mapped buffer the reader page is just swapped out<br /> with the last page written in the write buffer. If the reader page is the<br /> same as the commit buffer (the buffer that is currently being written to)<br /> it was assumed that it should never have missed events. If it does, it<br /> triggers a WARN_ON_ONCE().<br /> <br /> But there just happens to be one scenario where this can legitimately<br /> happen. That is on a commit_overrun. A commit overrun is when an interrupt<br /> preempts an event being written to the buffer and then the interrupt adds<br /> so many new events that it fills and wraps the buffer back to the commit.<br /> Any new events would then be dropped and be reported as "missed_events".<br /> <br /> In this case, the next page to read is the commit buffer and after the<br /> swap of the reader page, the reader page will be the commit buffer, but<br /> this time there will be missed events and this triggers the following<br /> warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780<br /> Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50<br /> RSP: 0018:ffff888121787dc0 EFLAGS: 00010002<br /> RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49<br /> RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8<br /> RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982<br /> R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00<br /> R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008<br /> FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __pfx_ring_buffer_map_get_reader+0x10/0x10<br /> tracing_buffers_ioctl+0x283/0x370<br /> __x64_sys_ioctl+0x134/0x190<br /> do_syscall_64+0x79/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f95c8de48db<br /> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00<br /> RSP: 002b:00007ffe037ba110 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffe037bb2b0 RCX: 00007f95c8de48db<br /> RDX: 0000000000000000 RSI: 0000000000005220 RDI: 0000000000000006<br /> RBP: 00007ffe037ba180 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffe037bb6f8 R14: 00007f95c9065000 R15: 00005575c7492c90<br /> <br /> irq event stamp: 5080<br /> hardirqs last enabled at (5079): [] _raw_spin_unlock_irqrestore+0x50/0x70<br /> hardirqs last disabled at (5080): [] _raw_spin_lock_irqsave+0x63/0x70<br /> softirqs last enabled at (4182): [] handle_softirqs+0x552/0x710<br /> softirqs last disabled at (4159): [] __irq_exit_rcu+0x107/0x210<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The above was triggered by running on a kernel with both lockdep and KASAN<br /> as well as kmemleak enabled and executing the following command:<br /> <br /> # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50<br /> <br /> With perf interjecting a lot of interrupts and trace-cmd enabling all<br /> events as well as function tracing, with lockdep, KASAN and kmemleak<br /> enabled, it could cause an interrupt preempting an event being written to<br /> add enough event<br /> ---truncated---