CVE Catalog

CVE-2026-89791

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.19%

9th percentile - higher than 9% of all known CVEs

Summary

A use-after-free vulnerability exists in the Linux kernel perf subsystem when perf mmap() revival races with the last munmap(). perf_mmap_close() drops rb->mmap_count without holding event->mmap_mutex, allowing a concurrent perf_mmap_rb() to reattach a buffer that is then freed while another process still has it mapped.

Risk Assessment

The vulnerability allows a local unprivileged user to trigger a page-level use-after-free, potentially leading to local privilege escalation to root. The default configuration (kernel.perf_event_paranoid=2) does not prevent this attack.

Recommendation

Update the Linux kernel to a version containing the fix that swaps the order of the event->mmap_count and rb->mmap_count updates to serialize with perf_mmap(). If immediate patching is not possible, consider restricting perf_event access by increasing kernel.perf_event_paranoid.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS