CVE-2026-89499

What it actually does

A race in the Linux kernel ring-buffer mishandles a failed remote reader page swap. When swap_reader_page returns -EBUSY (the writer advanced the head before the remote reader caught up, typically during an event storm on a small buffer), __rb_get_reader_page_from_remote() warned but continued with an unchanged reader ID and rearranged the local page list as if the swap had succeeded. The same page can be spliced as both the previous and new reader, corrupting ring-buffer metadata. That inconsistency can yield use-after-free, double-use of a buffer page, or other kernel memory corruption, with high impact on confidentiality, integrity, and availability from a local low-privilege context.

Why it matters to the business

An unprivileged local user can crash Linux hosts or, in a worst case, corrupt kernel memory in a way that enables privilege escalation, putting shared, multi-tenant, and developer workstations that use tracing at particular risk. Operational consequences include kernel panics, lost tracing data, and full host compromise. Exploit likelihood is currently low: EPSS is about 0.16% and flat over 30 days, exploit maturity is none, the issue is not in CISA KEV, and it is not associated with ransomware. Thirty-two days after publication, unpatched production kernels remain a standard patch-priority risk rather than an emergency mass-exploitation event.

How an attack unfolds

An attacker who already has local, low-privilege access on a vulnerable Linux kernel causes heavy tracing or ftrace activity against a small per-CPU ring buffer so the writer moves the head page before a remote reader finishes swapping. The swap callback returns -EBUSY, but the unpatched path keeps the old reader ID and still rewrites the local page list, leaving two list roles pointing at the same page. Later consume or produce operations on that corrupted reader state can free or reuse kernel memory under attacker-influenced timing. The result is typically a kernel oops or panic; with additional local primitives the same corruption can be steered toward information leak or code execution in kernel context. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Install a Linux kernel that includes the ring-buffer fix which treats a failed remote swap_reader_page as a recoverable error, reports it with pr_warn_ratelimited(), returns NULL, and does not rearrange the local page list. Prefer distribution-supplied kernel packages and reboot onto the patched kernel. Exact per-package fixed versions were not supplied with this record, so confirm against your vendor advisory or upstream commit that stops remote reader updates when page swap fails. Until you can reboot, reduce exposure by restricting unprivileged access to tracefs/debugfs and ftrace, keeping perf_event_paranoid conservative, and avoiding undersized ring buffers under heavy tracing. There is no complete configuration-only fix for the race.

How to confirm the fix worked

Inventory running kernels (uname -r and vendor package changelog) and confirm the ring-buffer remote-reader -EBUSY handling is present: failed swap must not continue with a stale reader ID. After patching and reboot, enable tracing, generate load on small buffers, and verify the kernel remains stable and that a failed remote swap yields a rate-limited warning and a NULL reader rather than list corruption or oops. Flag any host that still exposes ftrace, perf, or other ring-buffer interfaces to unprivileged users on a pre-fix kernel.

Typical attack path

1. Obtain local access as an unprivileged user on a Linux system running an unpatched kernel.
2. Ensure kernel tracing consumers are active so per-CPU ring buffers are allocated (ftrace, perf, or similar).
3. Drive a high-rate event storm against a small ring buffer so the writer advances the head before the remote reader completes a page swap.
4. Trigger the remote reader path so swap_reader_page returns -EBUSY while the kernel still rearranges the local page list.
5. Cause the same page to be treated as both previous and new reader, corrupting ring-buffer state.
6. Use the resulting kernel memory corruption to crash the host or attempt local privilege escalation.

How to detect it

There is no public exploit and no associated threat-actor tooling, so look for crash artifacts rather than a unique implant. Review kernel logs (journald/syslog/dmesg, vmcore, kdump) around oops, panic, WARN, and BUG involving ring-buffer reader page handling, especially under heavy ftrace or tracing load. Correlate with unprivileged processes opening tracing controls or generating extreme event rates against small buffers. Post-crash call traces naming ring-buffer reader swap paths are consistent with triggering this race (accidentally or deliberately) but are not proof of a successful privilege-escalation exploit. Absence of those logs does not prove the bug was never hit.

• __rb_get_reader_page_from_remote
• swap_reader_page
• rb_get_reader_page
• ring_buffer_swap_reader
• Call Trace:.*ring_buffer
• Oops:.*ring_buffer
• WARNING:.*ring.buffer
• pr_warn.*reader page

What your security team should do

• Patch and reboot Linux kernels to a build that includes the ring-buffer remote reader page-swap failure handling; treat this as normal high-severity local kernel hygiene, not a KEV emergency.
• Prioritize multi-user, CI, container-host, and jump-box systems where unprivileged users can enable tracing or generate event storms.
• Until patched, lock down tracefs/debugfs/ftrace and keep unprivileged perf/tracing access disabled.
• Hunt kernel logs for ring-buffer oopses and unexpected tracing use by non-admin accounts, then confirm those hosts are queued for the kernel update.
• Track vendor kernel advisories for exact package versions, since fixed-version metadata is not listed on this record.