CVE-2026-64300 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix page UAF in map_range()
map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via
perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are serialized by rb->aux_mutex, and mmap_mutex is per event.
Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows:
CPU 0 CPU 1 ===== ===== rb_alloc_aux() map_range() [1]: allocate rb->aux_pages[0]
[2]: rb->aux_nr_pages++
[3]: perf_mmap_to_page()
returns rb->aux_pages[0]
[4]: map it as VM_PFNMAP
[5]: rb->aux_pgoff = 1
munmap the page [6]: free rb->aux_pages[0]
Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame.
Fix this by taking rb->aux_mutex across the page walk in map_range().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists within the linux kernel's perf subsystem where a use-after-free condition can occur during auxiliary buffer management. The flaw specifically affects the map_range() function which processes performance monitoring data through the aux_pages array structure. The issue arises from insufficient synchronization between concurrent operations that access shared auxiliary memory resources, creating a race condition scenario that can lead to system instability and potential privilege escalation.
The technical implementation involves multiple kernel components working in concert where perf_mmap_to_page() accesses rb->aux_pages[], rb->aux_nr_pages, and rb->aux_pgoff fields while holding only event->mmap_mutex. However, these fields are properly serialized by rb->aux_mutex which is per ring buffer rather than per event. This architectural mismatch creates a scenario where multiple events can share the same ring buffer through PERF_EVENT_IOC_SET_OUTPUT ioctl call, allowing simultaneous execution of rb_alloc_aux() and map_range() operations.
The race condition unfolds through specific CPU execution paths where CPU 0 executes rb_alloc_aux() allocating memory pages and updating counters while CPU 1 concurrently runs map_range() which reads these values and creates mappings. The sequence begins with page allocation in rb_alloc_aux(), followed by incrementing auxiliary page count, then map_range() performs perf_mmap_to_page() which returns the allocated page, maps it as VM_PFNMAP, and finally updates the page offset. When the memory is subsequently unmapped, the original page gets freed while CPU 1 still maintains a mapping to the freed physical frame.
This vulnerability directly corresponds to CWE-416 Use After Free and falls under ATT&CK technique T1068 Exploitation for Privilege Escalation. The absence of reference counting protection for VM_PFNMAP pages creates a fundamental flaw in memory management where freed physical frames remain accessible through existing mappings, potentially allowing attackers to read from or write to deallocated kernel memory regions.
The operational impact extends beyond simple system instability as this vulnerability can be exploited to gain unauthorized access to kernel memory spaces. Attackers could potentially leverage the use-after-free condition to execute arbitrary code with kernel privileges, bypassing standard security mechanisms. The vulnerability affects systems running affected kernel versions where performance monitoring is active and multiple events share ring buffer resources through the ioctl interface.
Mitigation strategies include applying the kernel patch that properly synchronizes access by taking rb->aux_mutex across the page walk in map_range() function. This ensures that all operations accessing the auxiliary page array occur under proper mutual exclusion, preventing the race condition scenario. System administrators should prioritize updating to patched kernel versions and monitor for potential exploitation attempts through performance monitoring subsystems. Additionally, implementing runtime protections such as kernel address space layout randomization and controlling access to perf_event ioctl interfaces can provide additional defense-in-depth measures against exploitation of this vulnerability.