CVE-2026-23248

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix refcount bug and potential UAF in perf_mmap<br /> <br /> Syzkaller reported a refcount_t: addition on 0; use-after-free warning<br /> in perf_mmap.<br /> <br /> The issue is caused by a race condition between a failing mmap() setup<br /> and a concurrent mmap() on a dependent event (e.g., using output<br /> redirection).<br /> <br /> In perf_mmap(), the ring_buffer (rb) is allocated and assigned to<br /> event-&gt;rb with the mmap_mutex held. The mutex is then released to<br /> perform map_range().<br /> <br /> If map_range() fails, perf_mmap_close() is called to clean up.<br /> However, since the mutex was dropped, another thread attaching to<br /> this event (via inherited events or output redirection) can acquire<br /> the mutex, observe the valid event-&gt;rb pointer, and attempt to<br /> increment its reference count. If the cleanup path has already<br /> dropped the reference count to zero, this results in a<br /> use-after-free or refcount saturation warning.<br /> <br /> Fix this by extending the scope of mmap_mutex to cover the<br /> map_range() call. This ensures that the ring buffer initialization<br /> and mapping (or cleanup on failure) happens atomically effectively,<br /> preventing other threads from accessing a half-initialized or<br /> dying ring buffer.