CVE-2026-89747: tracing: Fix use-after-free in trace_pipe read on sub-buffer order change
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free in tracepipe read on sub-buffer order change
Writing to buffersubbufsizekb calls ringbuffersubbuforderset(), which frees every sub-buffer of the ring buffer, including the reader page, and replaces them with newly allocated ones.
Readers of tracepipe hold pointers into those pages. ringbufferpeek() looks up an event under cpubuffer->readerlock but returns the event pointer after dropping the lock, and peeknextentry() then calls ringbuffereventlength() and ringbuffereventdata() on it. If the sub-buffer order is changed in that window, the reader dereferences freed memory:
BUG: KASAN: use-after-free in ringbufferpeek+0x3e0/0x430 Read of size 1 at addr ffff88802a4cf010 by task syz-executor989/6002
Freed by: freebufferpage kernel/trace/ringbuffer.c:398 [inline] ringbuffersubbuforderset+0x1325/0x18e0 kernel/trace/ringbuffer.c:7444 buffersubbufsizewrite+0x182/0x280 kernel/trace/trace.c:8221
Take traceaccesslock(RINGBUFFERALLCPUS) around the order change. This is the lock tracepipe readers already hold across their entire peek-and-print loop, so the swap can no longer race with a reader that is dereferencing a peeked event.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify kernel tracing code so that when changing the ring buffer sub-buffer order (via ring_buffer_subbuf_order_set() called from buffer_subbuf_size_write), the write path takes trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change. This prevents a trace_pipe reader (holding reader pointers into ring buffer pages) from racing with the swap that can lead to use-after-free in ring_buffer_peek().
Linux kernel tracing (trace_pipe / ring_buffer) trace_pipe read synchronization: take trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change in ring_buffer_subbuf_order_set() = enabled
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
A trace_pipe reader must be active while buffer_subbuf_size_kb is written to change the ring buffer sub-buffer order. The resize can free and replace pages while the reader is using an event pointer obtained from the old pages.
Who is realistically exposed?
Systems where one actor can read trace_pipe while another can modify buffer_subbuf_size_kb are exposed to this race. The provided information does not establish that ordinary trace_pipe reads alone trigger the issue.
What can be done if the fix cannot be applied immediately?
Avoid changing buffer_subbuf_size_kb while trace_pipe is being read. Coordinate tracing configuration changes so readers have stopped before resizing the ring buffer.
How might this appear on an affected system?
The reported failure is a KASAN use-after-free during ring_buffer_peek(), with memory freed through ring_buffer_subbuf_order_set() after a buffer_subbuf_size_kb write. Such a report during concurrent trace_pipe reading and sub-buffer resizing is consistent with this issue.