CVE-2026-89500

The Linux kernel's tracing ring buffer caches a reader page (cpu_buffer::free_page); when that cached page is discarded after a concurrent ring-buffer resize, the kernel frees it using the buffer's new global subbuf_order instead of the order under which the page was originally allocated. This mismatched order is passed to the free_pages() call, which can crash the kernel or leak memory because the cached page was allocated under the old size. The flaw is local-only (CVSS 7.8, AV:L/PR:L), so an attacker needs a foothold on the machine and the ability to trigger a concurrent ring-buffer resize while a reader page is cached; the realistic outcome is a kernel panic (denial of service) or memory leak, despite the high confidentiality/integrity scores in the vector. The fix stores the page's actual allocation order alongside its address by converting free_page into a buffer_data_read_page structure, so the correct order is always used regardless of a stalled cpu_buffer->subbuf_order value. No public proof of concept or in-the-wild exploitation is known, and the issue is not on CISA's KEV list.

What to do: Apply distribution kernel updates once they include the fix (free_page stored as a buffer_data_read_page with its own order) and reboot to load the patched kernel. Prioritize multi-user servers, shared workstations, and container hosts, since the attack vector is local-only. As defense in depth, restrict access to tracing interfaces (tracefs, /sys/kernel/debug/tracing, perf) that drive ring-buffer resizes.