CVE-2025-38267
Publication date:
10/07/2025
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---
Severity CVSS v4.0: Pending analysis
Last modification:
10/07/2025