CVE-2026-64300 Overview
CVE-2026-64300 is a use-after-free vulnerability in the Linux kernel's performance events (perf) subsystem. The flaw resides in the map_range() function within the perf/aux code path. The function reads rb->aux_pages[], rb->aux_nr_pages, and rb->aux_pgoff via perf_mmap_to_page() while holding only event->mmap_mutex. These fields are serialized by rb->aux_mutex, creating a race condition when two events share a ring buffer through PERF_EVENT_IOC_SET_OUTPUT. Local attackers with low privileges can trigger the race to hold a mapping to a freed physical frame.
Critical Impact
Local low-privileged attackers can trigger a page use-after-free that grants access to freed physical memory, enabling privilege escalation and kernel memory corruption.
Affected Products
- Linux kernel versions containing the vulnerable perf/auxmap_range() implementation
- Distributions shipping affected kernel builds prior to the upstream fix
- Systems where unprivileged users can create perf events
Discovery Timeline
- 2026-07-25 - CVE-2026-64300 published to NVD
- 2026-07-27 - Last updated in NVD database
Technical Details for CVE-2026-64300
Vulnerability Analysis
The vulnerability affects the auxiliary (AUX) ring buffer mechanism used by the Linux perf subsystem for hardware trace data such as Intel PT. The map_range() function walks AUX pages while holding the per-event mmap_mutex, but the AUX page array is protected by the ring buffer's aux_mutex. This mismatch in locking creates a window where concurrent operations on the same ring buffer race against each other.
Two perf events can share a single ring buffer using the PERF_EVENT_IOC_SET_OUTPUT ioctl. When one thread invokes rb_alloc_aux() to allocate AUX pages, and another thread simultaneously calls map_range() on the shared ring buffer, the two paths do not serialize against each other. The result is a page use-after-free ([CWE-416]).
Root Cause
The root cause is inconsistent locking discipline for AUX ring buffer state. Fields aux_pages[], aux_nr_pages, and aux_pgoff are documented as protected by rb->aux_mutex, but map_range() accesses them under event->mmap_mutex only. Because mmap_mutex is per-event and events can share a ring buffer, the intended serialization does not hold.
Attack Vector
An attacker with local access and permission to create perf events triggers the race using the following sequence:
- Thread A calls rb_alloc_aux() and allocates rb->aux_pages[0], then increments rb->aux_nr_pages.
- Thread B enters map_range(), calls perf_mmap_to_page() which returns rb->aux_pages[0], and maps the page as VM_PFNMAP.
- Thread A sets rb->aux_pgoff = 1 and the mapped page is subsequently freed via munmap.
- Thread B retains a mapping to the freed physical frame.
Pages mapped as VM_PFNMAP carry no refcount protection. The attacker retains read/write access to physical memory that the kernel has reclaimed and potentially reallocated, enabling privilege escalation, kernel data disclosure, or arbitrary kernel memory corruption.
No verified public proof-of-concept code is available. See the upstream commits linked below for the exact code paths.
Detection Methods for CVE-2026-64300
Indicators of Compromise
- Unexpected kernel oops or general protection faults referencing perf_mmap_to_page, rb_alloc_aux, or map_range in dmesg logs
- KASAN reports flagging use-after-free on AUX pages under perf_event_open workloads
- Unprivileged processes issuing PERF_EVENT_IOC_SET_OUTPUT ioctls followed by rapid mmap/munmap cycles on perf file descriptors
Detection Strategies
- Audit perf_event_open syscall usage from non-root users and correlate with PERF_EVENT_IOC_SET_OUTPUT ioctl invocations
- Monitor kernel logs for KASAN or slab corruption warnings referencing perf ring buffer symbols
- Deploy syscall telemetry to flag processes creating multiple perf events that share ring buffers and repeatedly remap AUX regions
Monitoring Recommendations
- Enable kernel lockdown and KASAN in test environments to surface race-based UAF conditions before production exposure
- Restrict perf_event_paranoid sysctl to 2 or higher to limit unprivileged perf usage
- Aggregate kernel crash telemetry centrally to identify repeated crashes indicative of exploitation attempts
How to Mitigate CVE-2026-64300
Immediate Actions Required
- Apply the upstream kernel patches referenced in the Kernel Git Commit Fix, Kernel Git Commit Update, and Kernel Git Commit Patch as soon as distribution builds become available
- Restrict unprivileged access to perf_event_open by setting kernel.perf_event_paranoid=3 on systems that do not require user-mode profiling
- Inventory hosts exposing perf to untrusted local users, including multi-tenant containers and shared build systems
Patch Information
The upstream fix takes rb->aux_mutex across the page walk in map_range(), ensuring consistent serialization with rb_alloc_aux() and eliminating the race. Backports are being merged into stable kernel trees. Consult your distribution vendor's advisory for the specific kernel version containing the fix.
Workarounds
- Set kernel.perf_event_paranoid=3 via sysctl to block unprivileged perf_event_open calls
- Remove CAP_PERFMON and CAP_SYS_ADMIN from untrusted workloads and container profiles
- Disable the perf subsystem entirely on systems that do not require it by removing CONFIG_PERF_EVENTS in custom kernel builds
# Restrict unprivileged perf_event_open access
sudo sysctl -w kernel.perf_event_paranoid=3
echo 'kernel.perf_event_paranoid=3' | sudo tee /etc/sysctl.d/99-cve-2026-64300.conf
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
