CVE-2026-89747

The Linux kernel's tracing subsystem contains a use-after-free in which writing to the tracefs file buffer_subbuf_size_kb makes ring_buffer_subbuf_order_set() free and replace every ring-buffer sub-buffer, including the reader page, while a concurrent trace_pipe reader may still hold a pointer to a previously peeked event. Because ring_buffer_peek() returns that event pointer after dropping cpu_buffer->reader_lock, a race between the sub-buffer order change and the reader dereferencing the event leads to a use-after-free (KASAN-reported in ring_buffer_peek, found by syzbot fuzzing). Exploitation requires local code execution with privileges sufficient to write to tracefs (normally root or equivalent), so this is primarily a concern for sandbox/container escape scenarios, malicious privileged workloads, or multi-user systems that expose tracing to semi-trusted code; CVSS 3.1 is 7.8 with high impact to confidentiality, integrity, and availability, meaning a kernel memory disclosure, crash, or potential code execution primitive. All Linux kernel builds carrying the buffer_subbuf_size_kb sub-buffer order-change support are affected, though the advisory does not specify exact version ranges; the fix takes trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change, the same lock trace_pipe readers already hold. No public proof of concept or in-the-wild exploitation is known, and the issue is not in CISA's KEV catalog.

What to do: Apply your distribution's kernel updates as soon as the fix (taking trace_access_lock across the sub-buffer order change) is backported. Verify that no unprivileged users, containers, or workloads can write to tracefs (/sys/kernel/tracing, including buffer_subbuf_size_kb) — on container hosts, avoid bind-mounting host tracefs into containers and restrict tracing-related capabilities for untrusted workloads. If tracefs access is required by monitoring agents, ensure those agents run as the only writers and cannot be influenced by untrusted code.