CVE-2026-89748
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A mistake in the Linux kernel's internal tracing mechanism could let someone who already has access to the machine corrupt memory and potentially seize control of the entire system.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrect retry counter logic in simple_ring_buffer_swap_reader_page() causes either an erroneous -EBUSY return after a successful final page swap or pointer updates after a failed swap, resulting in ring buffer corruption or incomplete reader bookkeeping.
Why it matters to the business
Local attackers can trigger kernel memory corruption on Linux systems, leading to crashes, instability, or potential privilege escalation; the issue affects any kernel using the tracing ring buffer and has remained unpatched for over a month with no known widespread exploitation.
How an attack unfolds
A local attacker triggers tracing code paths that invoke the reader swap function, arranges for the retry counter to reach zero or below on the final attempt, and relies on the reversed !retry test to either abort a completed swap or apply a failed swap, corrupting ring state.
How to fix it
Apply the upstream fix that changes the exhaustion test to check only for a negative retry counter and return -EBUSY on that condition; rebuild and boot the corrected kernel on all affected systems.
How to confirm the fix worked
Inspect the patched simple_ring_buffer_swap_reader_page() to confirm the test now treats only negative values as exhaustion; run stress tests that repeatedly swap reader pages under tracing load to verify no corruption occurs.
Typical attack path
- Obtain local user access on an affected Linux host
- Enable or interact with kernel tracing to exercise the ring buffer reader swap path
- Craft repeated swap operations that exhaust the retry counter on the final attempt
- Leverage the resulting pointer or bookkeeping error to corrupt ring buffer metadata
How to detect it
Review kernel logs (dmesg, journalctl) for ring buffer or tracing subsystem errors around the time of suspected activity; correlate with processes that enable or interact with ftrace or perf tracing.
What your security team should do
- Patch Linux kernels to the corrected version as soon as vendor packages are available
- Restrict unprivileged access to tracing interfaces until patches are deployed
- Monitor kernel logs for ring-buffer or tracing related warnings and panics
The record
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix retry exhaustion in simple ring buffer reader swap simple_ring_buffer_swap_reader_page() starts with retry set to 8 and post-decrements it only after a failed link replacement. On the final attempt, a successful replacement leaves retry at zero, while a failed replacement leaves it at -1. The current !retry test reverses both outcomes. It returns an error after a successful final replacement, leaving the link update complete but the reader bookkeeping unfinished. After a failed final replacement, it falls through and updates the head and reader pointers as though the replacement succeeded, which can corrupt the ring. Treat only a negative counter as exhaustion and return the documented -EBUSY error.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|