CVE-2026-89500

What it actually does

A race in the Linux kernel tracing ring-buffer allows a cached reader page allocated under one sub-buffer order to be freed with a different order after a concurrent resize. free_pages() then uses a mismatched order versus the original allocation, which can corrupt the buddy page allocator, leak pages, panic the kernel, or produce memory corruption with high confidentiality, integrity, and availability impact (local, low privilege, no user interaction).

Why it matters to the business

Hosts that use kernel tracing or ftrace and allow buffer resize can suffer sudden kernel panics (outage) or, if memory corruption is weaponized, full host compromise by a local low-privilege user. Exploit maturity is none, EPSS remains very low (~0.0018, unchanged over 30 days), the CVE is not in CISA KEV, and no ransomware or named-actor use is reported. Residual risk is mainly availability and local privilege-escalation exposure on unpatched kernels until vendor updates are applied.

How an attack unfolds

An attacker with local (low-privilege) access needs the tracing ring buffer in use so a CPU buffer holds a cached reader page. They then race a ring-buffer resize—which updates the global subbuf_order—against discard of that cached page. The free path consults the new order instead of the order the page was allocated with, so the page allocator is given the wrong size. That mismatch can crash the kernel immediately or leave corrupted page-allocator state that a local attacker may try to turn into further kernel-memory corruption and privilege escalation. No public exploit or threat-actor campaign is known.

How to fix it

Apply the upstream Linux kernel fix that stores the cached free page as a buffer_data_read_page (address plus the actual allocation order) so discard never uses a stale cpu_buffer subbuf_order. Deploy the patched kernel from your distribution or stable tree as soon as it is available; there is no complete userspace workaround. Until patched, restrict who can enable tracing and resize buffers (typically CAP_SYS_ADMIN / root on tracing controls such as buffer size sysfs/debugfs), avoid concurrent tracing-buffer resizes on production hosts, and prefer kernels that already include the ring-buffer free_page order-tracking change.

How to confirm the fix worked

Confirm the running kernel includes the ring-buffer change that makes cpu_buffer::free_page a buffer_data_read_page (or equivalent vendor backport). Compare uname -r and distro changelog/CVE mapping against the patched package; on source trees, grep for the free_page/buffer_data_read_page change in kernel/trace/ring_buffer.c. After upgrade, reboot onto the new kernel, verify tracing still functions, and ensure no oopses appear when resizing the tracing buffer under load. Identify remaining unpatched hosts via inventory of kernel versions still lacking the fix.

Typical attack path

1. Gain local access on a Linux system running an affected kernel with tracing/ring-buffer available
2. Cause or wait for tracing activity so a CPU buffer caches a reader page at the current sub-buffer order
3. Concurrently resize the tracing ring buffer (changing subbuf_order) while the cached reader page is discarded
4. Trigger free_pages() with the new order against a page allocated at the old order
5. Induce kernel panic (denial of service) or attempt to abuse resulting page-allocator corruption for local privilege escalation

How to detect it

There are no network signatures or malware droppers for this issue. Hunt historically on unpatched kernels for evidence the race was hit: kernel oops/panic in ring-buffer or page-allocator paths around tracing buffer resize; dmesg/journal/serial console logs with bad page state, invalid order, or BUG in ring_buffer code; audit or auditd/syscalls showing writes to tracing buffer-size controls shortly before a crash. Correlate local user sessions and processes that touched /sys/kernel/tracing, /sys/kernel/debug/tracing, or equivalent tracefs buffer_size_kb around the event. Absence of oopses does not prove the bug was not triggered if the host was rebooted without log persistence.

• BUG: Bad page state
• page dumped because:
• kernel BUG at kernel/trace/ring_buffer.c
• Oops:.*ring_buffer
• Call Trace:.*rb_
• free_pages
• buffer_size_kb
• /sys/kernel/tracing/buffer_size_kb
• /sys/kernel/debug/tracing/buffer_size_kb
• tracefs

What your security team should do

• Patch and reboot Linux kernels to a build that includes the ring-buffer free_page order fix; treat as a local high-impact kernel race (CVSS 7.8) even though EPSS and KEV risk are currently low
• Inventory systems with kernel tracing/ftrace enabled or writable tracing controls and prioritize internet-facing or multi-tenant hosts
• Limit CAP_SYS_ADMIN and access to tracing buffer-size controls until kernels are patched
• Monitor kernel logs for ring-buffer/page-allocator oopses that could indicate triggering of this race
• Reassess after vendor advisories publish exact fixed package versions; no public exploit is known, so mass-exploitation urgency is lower than KEV issues