Cloudanix VulnDB

CVE-2026-89747

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's tracing feature could let a logged-in user crash the system or take full control by changing a tracing setting while another process is reading trace data.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free when a trace_pipe reader holds a pointer to a ring-buffer event that is freed during a concurrent sub-buffer order change performed by buffer_subbuf_size_kb.

Why it matters to the business

Local attackers can crash the kernel or execute arbitrary code, leading to denial of service or full host compromise on systems exposing tracing interfaces to untrusted users.

How an attack unfolds

An attacker with local access opens trace_pipe and begins reading events while simultaneously writing a new sub-buffer size to trigger ring_buffer_subbuf_order_set, freeing the page the reader is about to dereference after the lock is dropped.

How to fix it

Apply the upstream fix that wraps ring_buffer_subbuf_order_set with trace_access_lock(RING_BUFFER_ALL_CPUS); rebuild and reboot onto a kernel containing the corrected ring-buffer logic.

How to confirm the fix worked

Confirm the presence of the trace_access_lock acquisition around buffer_subbuf_size_write and ring_buffer_subbuf_order_set in the running kernel source or binary; re-test the original KASAN reproducer to verify absence of the use-after-free.

Typical attack path

  1. Obtain local shell on the target system
  2. Open /sys/kernel/debug/tracing/trace_pipe for reading
  3. Write a new value to buffer_subbuf_size_kb in another thread or process
  4. Trigger ring_buffer_peek and subsequent event access after the sub-buffers are replaced
  5. Dereference freed memory to achieve KASAN-detected use-after-free

How to detect it

Search kernel logs for KASAN use-after-free reports mentioning ring_buffer_peek or ring_buffer_subbuf_order_set; inspect audit logs for writes to buffer_subbuf_size_kb while trace_pipe is open.

What your security team should do

  • Patch kernels to the version containing the trace_access_lock change as soon as vendor packages are available
  • Restrict unprivileged access to /sys/kernel/debug/tracing and trace_pipe via mount options or LSM policy
  • Monitor for local privilege-escalation attempts targeting the tracing subsystem

The record

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.

Affected packages

Ecosystem Package Introduced Fixed