CVE-2026-89501

What it actually does

A race condition in the Linux kernel tracing ring-buffer allows ring_buffer_subbuf_order_set() to clear cpu_buffer->free_page without holding cpu_buffer::lock, racing with ring_buffer_alloc_read_page() and ring_buffer_free_read_page(). The resulting inconsistent page pointers can cause use-after-free or double-free of kernel ring-buffer pages and broader kernel memory corruption, with high impact on confidentiality, integrity, and availability (local, low-privilege, no user interaction).

Why it matters to the business

A logged-in user with ordinary privileges could crash a Linux host or escalate to kernel-level control, disrupting operations and enabling further compromise of data and workloads. The issue is not in CISA KEV, is not associated with ransomware, has no known in-the-wild exploitation, and has a very low, flat EPSS (~0.0017 over 30 days). It has been public for about a month; unpatched kernels that expose tracing or ring-buffer interfaces to untrusted local users still present a local privilege-escalation and availability risk.

How an attack unfolds

An attacker with a local low-privilege account concurrently exercises tracing ring-buffer paths: one path resizes sub-buffers (changing subbuf order, which can clear the per-CPU free_page pointer without the required lock) while another path allocates or frees reader pages. Winning the race leaves kernel page state inconsistent, which can panic the kernel or be abused for memory corruption and local privilege escalation. No named threat actors or campaigns are tied to this CVE, and exploit maturity is none.

How to fix it

Install the Linux kernel update from upstream or your distribution that holds cpu_buffer::lock around sub-buffer resize so ring_buffer_subbuf_order_set() cannot race with ring_buffer_alloc_read_page() and ring_buffer_free_read_page(). Exact patched package versions were not supplied with this record; follow your vendor kernel advisory and reboot into the patched kernel. Until patched, restrict unprivileged access to tracing and ring-buffer controls (limit tracefs/debugfs and related perf/ftrace interfaces) and do not expose those interfaces to untrusted local users or multi-tenant workloads.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory includes the ring-buffer fix that takes cpu_buffer::lock when resizing a subbuf. Compare the installed kernel package against the patched release, then reboot and verify uname and package version. After patching, confirm tracing still operates as expected and that unprivileged users cannot change subbuf order if that is your policy. Inventory whether tracefs or debugfs is mounted and which users can access it.

Typical attack path

1. Obtain local low-privilege access on an affected Linux host
2. Confirm tracing or ring-buffer interfaces (for example ftrace/perf/tracefs) are reachable to that account
3. Trigger concurrent sub-buffer resize (subbuf order change) and reader-page allocate/free operations
4. Win the race so free_page is cleared or reused while another path still references it
5. Cause kernel memory corruption that results in a panic/oops or local privilege escalation
6. Use elevated kernel privileges for persistence, credential access, or further host compromise

How to detect it

This is a local kernel race with no network signature and no public exploit artifacts. Look for evidence the race already fired rather than a unique implant: kernel logs (dmesg, journalctl -k, /var/log/kern.log, /var/log/messages), kdump/vmcore, and crash/oops reports mentioning ring-buffer reader-page or subbuf-resize functions, unexpected page-allocator BUGs, use-after-free, or NULL-pointer dereferences in tracing code. Correlate with local processes that opened tracing or perf interfaces around the time of the oops. Absence of these logs does not prove the race was never hit; presence of a matching oops on an unpatched kernel warrants treating the host as potentially compromised.

• ring_buffer_subbuf_order_set
• ring_buffer_alloc_read_page
• ring_buffer_free_read_page
• cpu_buffer->free_page
• BUG: kernel NULL pointer dereference.*ring_buffer
• Unable to handle kernel paging request.*ring_buffer
• use-after-free.*ring_buffer

What your security team should do

• Prioritize kernel updates on multi-user, container-host, and CI systems where untrusted local users can reach tracing interfaces, even though EPSS is low and the CVE is not in KEV
• Patch and reboot to a kernel that holds cpu_buffer::lock during subbuf resize; track vendor advisories for exact package versions
• Until patched, tighten permissions on tracefs/debugfs and related ftrace/perf controls so unprivileged users cannot resize or allocate ring-buffer pages
• Hunt historical kernel oops/panic and kdump artifacts for ring-buffer page allocator races as a sign the bug was triggered
• Treat any confirmed local kernel memory corruption on unpatched hosts as a potential privilege-escalation event and follow incident-response procedures