PT-2026-90463 · Linux · Linux

CVE-2026-89747

·

Published

2026-09-11

·

Updated

2026-09-11

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free in trace pipe read on sub-buffer order change
Writing to buffer subbuf size kb calls ring buffer subbuf order set(), which frees every sub-buffer of the ring buffer, including the reader page, and replaces them with newly allocated ones.
Readers of trace pipe hold pointers into those pages. ring buffer peek() looks up an event under cpu buffer->reader lock but returns the event pointer after dropping the lock, and peek next entry() then calls ring buffer event length() and ring buffer event data() on it. If the sub-buffer order is changed in that window, the reader dereferences freed memory:
BUG: KASAN: use-after-free in ring buffer peek+0x3e0/0x430 Read of size 1 at addr ffff88802a4cf010 by task syz-executor989/6002
Freed by: free buffer page kernel/trace/ring buffer.c:398 [inline] ring buffer subbuf order set+0x1325/0x18e0 kernel/trace/ring buffer.c:7444 buffer subbuf size write+0x182/0x280 kernel/trace/trace.c:8221
Take trace access lock(RING BUFFER ALL CPUS) around the order change. This is the lock trace pipe 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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-89747

Affected Products

Linux