CVE-2026-89502

What it actually does

The Linux kernel tracing ring buffer allocated cpu_buffer::free_page with subbuf_order but freed it with the wrong order when sub-buffers used order greater than 0. A mismatched high-order free corrupts the buddy page allocator (inconsistent free lists, bad page state, possible double-free or use-after-free of physical pages). Resulting failures include kernel oops/panic, silent memory corruption of later allocations, and undefined behavior in any subsystem that reuses those pages. The bug lives in in-kernel tracing (ftrace ring-buffer) memory management, not in a userspace protocol parser.

Why it matters to the business

Linux hosts that use kernel tracing with larger-than-page sub-buffers can crash or become unstable, interrupting workloads and losing in-flight work until reboot. Default single-page sub-buffer setups are less exposed than observability, debugging, or performance-lab kernels that raise subbuf_order. The issue is not in CISA KEV, is not associated with ransomware, has no public exploit (maturity none), and EPSS is very low and flat (~0.002 over 30 days). Thirty-two days after publication there is no sign of mass exploitation, so treat this as a standard kernel hygiene patch rather than an emergency KEV-style outage.

How an attack unfolds

An attacker with local access (or a process allowed to configure tracing) enables the kernel ring buffer with sub-buffer order greater than zero so free_page is a high-order allocation. Teardown or spare-page handling then frees that page with the incorrect order, corrupting the buddy allocator. The attacker continues to exercise kernel allocations hoping to reclaim corrupted pages and turn allocator inconsistency into a crash or a further memory-safety primitive. No public exploit, proof of concept, or named threat-actor campaign is tied to this CVE; successful conversion to reliable privilege escalation is not demonstrated.

How to fix it

Install the Linux kernel update from your distribution or upstream that includes the ring-buffer fix titled roughly “ring-buffer: Free cpu_buffer::free_page with subbuf_order,” then reboot onto that kernel. Exact package versions were not supplied with this record—use vendor changelogs and kernel git history for the matching commit. Until patched, avoid configuring tracing sub-buffers with order greater than 0, restrict who can write tracefs/debugfs tracing controls (typically CAP_SYS_ADMIN), and do not expose tracing controls to untrusted tenants. There is no application-level workaround; the defect is in kernel page free-order handling.

How to confirm the fix worked

Confirm the running kernel changelog or package notes mention freeing cpu_buffer::free_page with subbuf_order (or the equivalent vendor advisory). After install, reboot and verify uname -r matches the patched package. In kernel source or distro patches, allocation and free of cpu_buffer->free_page must use the same order (subbuf_order / __free_pages with that order), not order 0. Spot-check that tracing still functions with default and, if used, high-order sub-buffers, and watch dmesg for buddy or bad-page-state warnings after enabling and tearing down tracing.

Typical attack path

1. Obtain local access on a vulnerable Linux kernel (unprivileged user or a process that can configure tracing/tracefs).
2. Enable ftrace/ring-buffer tracing with sub-buffer order greater than 0 so cpu_buffer::free_page is allocated as a high-order page.
3. Trigger ring-buffer spare-page or CPU-buffer teardown so free_page is released with the wrong order.
4. Cause buddy-allocator free-list corruption (bad page state, overlapping page ownership).
5. Attempt to reclaim corrupted pages via further kernel allocations and convert the corruption into a crash or follow-on memory-safety abuse.
6. No in-the-wild ransomware or APT playbook is documented for this CVE.

How to detect it

This defect leaves kernel-memory artifacts, not a distinct network implant. Hunt historical kernel logs, kdump/vmcore, and serial/console output from before the patch for buddy-allocator and bad-page-state reports around tracing teardown, especially on hosts that used high-order sub-buffers. Review dmesg, journalctl -k, /var/log/kern.log, and crash dumps for oopses whose call traces include ring_buffer, rb_free_cpu_buffer, or page-free paths, and for “Bad page state” / “page dumped because” messages. Correlate with users enabling tracing (writes under /sys/kernel/tracing or /sys/kernel/debug/tracing, perf/ftrace usage). Absence of these logs does not prove non-exploitation; presence of allocator corruption near tracing is suggestive of the bug firing, not of a specific named actor. No ransomware or APT telemetry is associated with this CVE.

• BUG: Bad page state
• page dumped because:
• bad page state
• kernel BUG at mm/page_alloc
• corrupted page
• Call Trace:.*ring_buffer
• rb_free_cpu_buffer
• cpu_buffer->free_page
• __free_pages
• journalctl -k ring_buffer
• /sys/kernel/tracing
• /sys/kernel/debug/tracing

What your security team should do

• Patch and reboot Linux kernels with the ring-buffer free_page order fix as part of the next planned kernel maintenance window; this is not a CISA KEV emergency.
• Inventory hosts that enable ftrace/perf/tracing with non-default sub-buffer order and patch those first.
• Limit tracefs/debugfs tracing configuration to trusted administrators until kernels are patched.
• Track vendor kernel advisories for the exact package version; this record does not list fixed versions.
• Do not prioritize hunting or emergency change based on EPSS or KEV—both indicate low current exploitation likelihood.
• After patching, sample kernel logs for lingering buddy-allocator or bad-page-state errors that may indicate pre-patch instability.