GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel perf AUX buffer: missing aux_mutex in map_range lets a local user map a freed page

CVE-2026-64300Kernel, userspace & hypervisorcurated

Impact

map_range() walks rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff holding only the per-event mmap_mutex, while those fields are serialized by rb->aux_mutex. Two events sharing one ring buffer through PERF_EVENT_IOC_SET_OUTPUT can therefore race rb_alloc_aux() against the mmap and install a mapping to a page that is subsequently freed. The mapping is VM_PFNMAP, which carries no refcount, so the process keeps read/write access to a physical frame after it is returned to the allocator and reused - a straightforward local privilege escalation primitive, or a host crash. This matters on GPU nodes because profiling is often deliberately left reachable for tenants so Nsight and perf workflows function: relaxed kernel.perf_event_paranoid, or CAP_PERFMON granted to profiling pods. Where perf_event_open is root-only, so is this bug. An AUX-capable PMU (Intel PT, Arm SPE/CoreSight) must be present for the AUX path to exist at all.

Who can reach it

Local user on the node who can call perf_event_open - unprivileged if perf_event_paranoid is relaxed or the pod holds CAP_PERFMON, otherwise root. No network path. Requires an AUX-capable PMU on the host.

What to do

Take a stable kernel carrying the fix (commits linked in the record) and reboot each node; perf is core kernel with no module to unload, so this is a drain-and-reboot per node, not a hot patch. Cheap interim mitigation that needs no maintenance window: set kernel.perf_event_paranoid=3 and drop CAP_PERFMON from tenant pods, which closes the path at the cost of tenant profiling.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.