CVE-2026-64300: perf/aux: Fix page UAF in map_range()
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix page UAF in maprange()
maprange() reads rb->auxpages[], rb->auxnrpages and rb->auxpgoff via perfmmaptopage() while holding only event->mmapmutex. Those fields are serialized by rb->auxmutex, and mmapmutex is per event.
Thus, two events sharing one rb via PERFEVENTIOCSETOUTPUT can race rballocaux() with maprange(), leading to a page-UAF scenario as follows:
CPU 0 CPU 1 ===== ===== rballocaux() maprange() [1]: allocate rb->auxpages[0] [2]: rb->auxnrpages++ [3]: perfmmaptopage() returns rb->auxpages[0] [4]: map it as VMPFNMAP [5]: rb->auxpgoff = 1
munmap the page [6]: free rb->auxpages[0]
Pages mapped as VMPFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame.
Fix this by taking rb->auxmutex across the page walk in maprange().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Fix the described race/UAF by taking rb->aux_mutex across the page walk in map_range(), so map_range() is serialized with rb_alloc_aux() when it allocates/free/updates rb->aux_pages, rb->aux_nr_pages, and rb->aux_pgoff.
Linux kernel rb->aux_mutex locking in map_range() = Hold rb->aux_mutex across the page walk in map_range() - Configuration
Ensure perf_mmap_to_page() takes the required synchronization (holding only event->mmap_mutex as described in the text) so that the map_range()/rb_alloc_aux() interaction cannot race and map VM_PFNMAP pages to freed physical frames.
Linux kernel Locking in perf_mmap_to_page() = Hold event->mmap_mutex while mapping
Event History
Frequently Asked Questions
What conditions are required to trigger the race?
An attacker needs local access with low privileges and must be able to use perf events. The race requires two events to share a ring buffer through PERF_EVENT_IOC_SET_OUTPUT while auxiliary-buffer allocation and map_range() run concurrently.
What is the impact if the race succeeds?
The race can leave a VM_PFNMAP mapping pointing to a freed physical frame because those mappings do not provide page-reference protection. This creates a use-after-free condition with potential confidentiality, integrity, and availability impact.
How can I determine whether the kernel includes the fix?
Check whether the kernel contains the change that holds rb->aux_mutex for the full page walk in map_range(). The provided stable-tree references identify commits carrying that fix.