CVE-2026-89503

What it actually does

A race in the Linux kernel tracing ring-buffer allows concurrent sub-buffer order changes (ring_buffer_subbuf_order_set) and reader-page allocation (ring_buffer_alloc_read_page) so that a reader page’s recorded order can disagree with the size of memory actually allocated. That mismatch can produce incorrect page sizing, out-of-bounds access, or other memory-safety failures in the ring-buffer/tracing path, with confidentiality, integrity, and availability all rated high for a local, low-privilege caller.

Why it matters to the business

On affected Linux hosts this is a local memory-safety defect in a core tracing subsystem: a low-privilege process can crash the kernel or, in a successful corruption case, gain higher privileges and take over the machine. Operational impact is highest on multi-tenant servers, developer workstations, and any system where untrusted local users or containers can reach ftrace/perf/ring-buffer interfaces. Exploit maturity is none, EPSS is very low (~0.00175 and flat over 30 days), and the CVE is not in CISA KEV and is not associated with ransomware, so mass remote compromise is unlikely; residual risk is still material wherever local access is common and kernels remain unpatched more than a month after publication.

How an attack unfolds

An attacker who already has a local unprivileged (or container) foothold triggers tracing or perf ring-buffer use while another thread or process resizes sub-buffer order. The allocator can record one order while the page was allocated under another, so later ring-buffer reads or writes operate on a page of the wrong size. That corruption is then used as a kernel memory-safety primitive (overflow, wrong-sized free, or similar) to disrupt tracing, panic the host, or attempt privilege escalation. No public exploit, named threat actor, or KEV campaign is associated with this issue; abuse would be opportunistic and local rather than wormable.

How to fix it

Apply the upstream Linux kernel fix that allocates the reader page using the order stored on the buffer page (bpage->order) so allocation size cannot diverge from the recorded order if subbuf_order changes mid-function. Deploy a vendor or distro kernel that includes this ring-buffer race fix; rebuild custom kernels from a tree that contains the patch. Until patched, restrict untrusted local users and containers from tracing/perf/debugfs ring-buffer controls (capability and mount policy), and avoid exposing sub-buffer resize to untrusted processes. No package-specific fixed versions were supplied with this record—track your distribution’s kernel advisory and install the first release that cites this CVE or the ring-buffer subbuf resize race fix.

How to confirm the fix worked

Confirm the running kernel changelog, distro advisory, or stable commit list includes the ring-buffer fix for the alloc_read_page vs subbuf_order_set race (allocation keyed off bpage->order). Compare uname -r and package version against the vendor’s patched kernel. On still-vulnerable builds, inventory who can access tracing/perf/ring-buffer interfaces. After patching, regression-test tracing (ftrace/perf record and ring-buffer consumers) under concurrent sub-buffer order changes and confirm no kernel warnings or oopses in that path.

Typical attack path

1. Obtain local code execution or a shell as an unprivileged user or in a container that can use kernel tracing/perf interfaces.
2. Open or mmap a tracing ring buffer (ftrace/perf/debugfs-style consumer) so ring_buffer_alloc_read_page runs.
3. Concurrently change sub-buffer order so ring_buffer_subbuf_order_set races with that allocation.
4. Cause a reader page whose stored order does not match allocated size.
5. Use the resulting kernel memory corruption for denial of service or, if corruption is controllable, local privilege escalation.
6. With elevated privileges, persist, disable defenses, or move laterally on the host.

How to detect it

There are no reliable network signatures or public exploit artifacts. Look for post-exploitation effects on hosts that ran unpatched kernels after publication: kernel oops/panic stacks mentioning ring_buffer, ring_buffer_alloc_read_page, ring_buffer_subbuf_order_set, or ftrace/perf ring-buffer code; unexpected tracing subsystem failures; and local privilege-escalation follow-on (new root processes, unexpected kernel module loads). Review syslog/journald/dmesg, vmcore/kdump, audit logs for tracing device access, and container runtimes that mount tracefs/debugfs. Absence of these artifacts does not prove the race was not attempted.

• ring_buffer_alloc_read_page
• ring_buffer_subbuf_order_set
• kernel oops: ring_buffer
• tracefs
• /sys/kernel/tracing
• /sys/kernel/debug/tracing

What your security team should do

• Patch Linux kernels to a build that contains the ring-buffer reader-page order race fix; treat multi-tenant and developer fleets as first wave even though EPSS and KEV risk are low.
• Until patched, limit CAP_SYS_ADMIN/perf/ftrace and debugfs/tracefs exposure for untrusted users and containers.
• Hunt for unexpected local privilege-escalation or kernel oops activity on hosts that were unpatched after the 2026-09-11 publication date.
• Track distro kernel advisories for the exact package version that closes this CVE; no per-package fixed versions were provided here.
• Do not prioritize this as an internet-facing emergency; keep it in the local LPE/kernel hygiene queue rather than a KEV-style crash patch.