HIGH Introduced in 6.18
perf MmapRevival UAF
CVE-2026-89791
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI6.6MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire "revival" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 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.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless.
02KernelScan AI Analysis
Risk summary
Any unprivileged local user can exploit a use-after-free in the perf events ring buffer lifecycle to escalate privileges to root. The race between munmap cleanup and concurrent mmap revival frees a buffer still mapped by another process, giving the attacker a page-level use-after-free primitive. Products that allow untrusted local code, host containers, or provide interactive shell access are most at risk.
Vulnerability analysis
When a process unmaps a perf event ring buffer, the cleanup path drops the buffer's reference count without holding the event mutex, creating a window in which a concurrent mapping from another process can revive the buffer. The cleanup then proceeds to free the newly revived buffer while the other process still has it mapped, producing a page-level use-after-free. The fix reorders the teardown so the event-level reference count is dropped first under its mutex, serializing the final drop to zero with any concurrent revival; the buffer-level count is only decremented afterward, so a zero result correctly indicates all users are detached and teardown can proceed safely. Any unprivileged local user can trigger this via the perf event system calls under the default kernel configuration, requiring no special capabilities or hardware.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 6.18 | 6.18.52 | 929cb3b9dc81 |
| 7.2 | 6.18 | 7.2.5 | 0c739f54f1c7 |
| mainline | 6.18 | 7.3 | 58a8108bc73d |