Linux CVE-2026-23248

Requires local user access to a Linux system running an affected kernel version. Attacker must trigger a race condition between failing mmap() setup and concurrent mmap() on dependent perf events with output redirection. No user interaction needed.

While CVSS and EPSS scores are not provided, this vulnerability presents moderate-to-high real-world risk. The attack vector is local (requires execution on the target system), but the attack complexity is low—an unprivileged user can trigger the race condition through concurrent mmap() calls on dependent events (inherited events or output redirection). The technical impact is denial of service via kernel crash or hung processes; kernel exploitation for privilege escalation is theoretically possible but not the primary impact. KEV status is unknown, and no public proof-of-concept code is confirmed available beyond Syzkaller reports, reducing immediate exploitation risk. However, the vulnerability was discovered via automated fuzzing (Syzkaller), indicating reproducibility. The presence of patches across three kernel versions (6.18.17, 6.19.7, 7.0-rc2) and three specific commit hashes suggests this was actively tracked and prioritized by Linux maintainers. From an SSVC perspective: exploitation is not currently known to be in the wild, but the attack is automatable (fuzzing demonstrated this), and technical impact is limited to denial of service rather than full system compromise. Real-world risk is highest for systems running unpatched kernels in multi-user or container environments where local attackers have process execution capability.

A local attacker on a multi-user system or container host creates two threads: the first thread initiates mmap() on a performance event, triggering ring buffer allocation and map_range(). Meanwhile, a second thread creates a child process that inherits the event or attaches to it via output redirection, attempting to increment the ring buffer's refcount. If the first thread's map_range() fails (due to memory pressure or resource limits), the cleanup path decrements the refcount to zero precisely when the second thread attempts to increment it, causing a refcount_t saturation warning and potential kernel panic or hung process. This can be triggered repeatedly via fuzzing or orchestrated via performance monitoring APIs (perf_event_open syscall) to cause sustained denial of service affecting the entire system's stability.