CVE-2026-99158

What it actually does

Race condition in ring_buffer_map_get_reader() causes NULL return from rb_get_reader_page() (when reader catches up to committing writer) to be treated as error, emitting false warning despite existing no-data handling path.

Why it matters to the business

Spurious kernel warnings during normal tracing or performance monitoring workloads can trigger unnecessary alerts, complicate log analysis, and increase operational noise for Linux systems using ring buffers.

How an attack unfolds

An attacker with local access triggers mmap reader operations concurrently with writers still committing events, causing the function to hit the unhandled NULL case and log a warning; no privilege escalation or data compromise occurs.

How to fix it

Apply the upstream kernel patch that routes NULL returns through the existing no-data exit path and removes the redundant reader_page == commit_page check; rebuild and reboot with the corrected kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting ring_buffer.c for the updated NULL handling logic; run stress tests exercising concurrent mmap readers and writers to verify absence of the warning.

Typical attack path

1. Obtain local unprivileged access on Linux host
2. Open and mmap a ring buffer (e.g., via perf or ftrace)
3. Time writes to advance commit_page before length is published
4. Trigger reader catch-up that returns NULL from rb_get_reader_page()
5. Observe false warning emitted by ring_buffer_map_get_reader()

How to detect it

Search kernel logs (dmesg, journalctl) and tracing output for warnings originating from ring_buffer_map_get_reader or mentions of NULL reader page during active mmap usage.

What your security team should do

• Prioritize patching production kernels that expose ring buffers to untrusted local users
• Monitor kernel logs for the specific false-warning string until patched
• Limit unprivileged access to perf_event_open and similar interfaces where feasible