CVE-2026-23248
Description
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix refcount bug and potential UAF in perf_mmap
Syzkaller reported a refcount_t: addition on 0; use-after-free warning in perf_mmap.
The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection).
In perf_mmap(), the ring_buffer (rb) is allocated and assigned to event->rb with the mmap_mutex held. The mutex is then released to perform map_range().
If map_range() fails, perf_mmap_close() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning.
Fix this by extending the scope of mmap_mutex to cover the map_range() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Race condition in Linux kernel perf_mmap leads to refcount underflow and potential use-after-free when mmap fails during concurrent access.
Vulnerability
Description A race condition exists in the Linux kernel's perf subsystem (perf/core) within the perf_mmap() function. When a call to mmap() on a perf event fails after the ring buffer (rb) has been allocated but before the mapping is finalized, cleanup triggers perf_mmap_close() which drops the reference count of the ring buffer. However, because the mmap_mutex is released before map_range() is called, another thread can concurrently attach to the same event (e.g., via inherited events or output redirection) and attempt to increment the reference count on a ring buffer that is being torn down [1]. This leads to a refcount_t addition on 0 warning and a potential use-after-free (UAF) condition.
Attack
Vector and Prerequisites Exploitation requires an attacker to have the ability to create and mmap() perf events on a system, which typically necessitates local access and the perf_event_open() system call capability. The race is triggered by having one thread perform a failing mmap() (e.g., due to resource limits) while another thread concurrently attaches to the same event through output redirection or inherited events. The successful exploitation depends on precise timing to win the race [2].
Impact
An attacker who successfully triggers the race can cause a use-after-free condition, leading to memory corruption. This could result in privilege escalation (by overwriting kernel memory) or a denial of service (system crash). The vulnerability is rated High with a CVSS v3 score of 7.8, indicating significant potential for local privilege escalation.
Mitigation
The fix extends the scope of the mmap_mutex to cover the entire mmap setup and cleanup path, ensuring atomicity of ring buffer initialization and mapping (or failure cleanup). This prevents concurrent threads from accessing a ring buffer in an inconsistent state [3]. The fix has been backported to stable kernel trees; users should apply the latest kernel updates from their distribution.
AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
3News mentions
0No linked articles in our index yet.