CVE-2026-89791: perf: Fix use-after-free when perf mmap() revival races with the last munmap()
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix use-after-free when perf mmap() revival races with the last munmap()
perfmmapclose() drops rb->mmapcount without holding event->mmapmutex (the refcountdecandtest() right before the refcountdecandmutexlock() of event->mmapcount). A concurrent perfmmaprb() can slot its entire "revival" path into that window (perfmmap holds event->mmapmutex for its whole duration, including rballoc):
munmap side (perfmmapclose) mmap side (perfmmaprb) ----------------------------------- -------------------------------- rb->mmapcount 1 -> 0 (no lock) (holds event->mmapmutex) incnotzero(rb->mmapcount) fails ringbufferattach(event, NULL) rballoc() + attach new rb refcountset(&event->mmapcount, 1) lock; event->mmapcount 1 -> 0 ringbufferattach(event, NULL) ringbufferput() -> frees the new rb
The revival's refcountset(&event->mmapcount, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perfeventparanoid=2).
Swap the order of the two counter updates: event->mmapcount is dropped first via refcountdecandmutexlock(), so its 1 -> 0 transition and the ringbufferattach() stay serialized with perfmmap(). rb->mmapcount == 0 then implies every event using the buffer is detached already, so the result of the rb->mmapcount drop can gate the remaining teardown directly and detachrest is no longer needed.
An earlier fix for this race from Kyle Zeng and David Lee takes event->mmapmutex around both counter updates [0]; here the not-last close stays lockless.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue under the default configuration?
Any unprivileged local user can exploit it to escalate privileges to root when the default kernel.perf_event_paranoid=2 setting is in use.
What conditions are required for exploitation?
An attacker needs local access and must race perf mmap() revival against the final munmap() of a perf ring buffer. The race can cause a newly revived buffer to be freed while another process still has it mapped, creating a page-level use-after-free.