GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel perf: use-after-free on the perf ring buffer when mmap setup fails during a concurrent attach

CVSS 7.8CVE-2026-23248Kernel, userspace & hypervisorcurated

Impact

perf_mmap() assigns the new ring buffer to event->rb, then drops mmap_mutex to call map_range(). If map_range() fails, the cleanup path drops the refcount to zero, but in the window where the mutex is not held another thread attaching to the same event - via inherited events or output redirection - can see the still-valid event->rb and take a reference on it. Syzkaller reproduced it as a refcount addition on 0, the classic precursor to a use-after-free on freed kernel memory. For a GPU fleet this matters wherever profiling is allowed to unprivileged users or inside containers: perf is routinely opened up so tenants can profile CUDA and framework workloads, and that same access is the exploit surface for a local privilege escalation on a shared node.

Who can reach it

Local user able to call perf_event_open and mmap the result - unprivileged if perf_event_paranoid is relaxed or the container is granted CAP_PERFMON, which is common on nodes where tenants profile their own jobs. Not reachable over the network.

What to do

Apply the stable kernel update that holds mmap_mutex across map_range(); three stable branches carry the fix. Rollout is drain, install kernel, reboot the node. Until the window can be scheduled, tightening kernel.perf_event_paranoid and dropping CAP_PERFMON from tenant containers removes unprivileged access to the path, at the cost of taking profiling away from tenants.

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.