{"id":"CVE-2026-89791","published":"2026-09-16T09:17:09.930","lastModified":"2026-09-16T15:18:09.253","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix use-after-free when perf mmap() revival races with the last munmap()\n\nperf_mmap_close() drops rb->mmap_count *without* holding\nevent->mmap_mutex (the refcount_dec_and_test() right before the\nrefcount_dec_and_mutex_lock() of event->mmap_count). A concurrent\nperf_mmap_rb() can slot its entire \"revival\" path into that window\n(perf_mmap holds event->mmap_mutex for its whole duration, including\nrb_alloc):\n\n  munmap side (perf_mmap_close)          mmap side (perf_mmap_rb)\n  -----------------------------------    --------------------------------\n  rb->mmap_count 1 -> 0   (no lock)      (holds event->mmap_mutex)\n                                         inc_not_zero(rb->mmap_count) fails\n                                         ring_buffer_attach(event, NULL)\n                                         rb_alloc() + attach new rb\n                                         refcount_set(&event->mmap_count, 1)\n  lock; event->mmap_count 1 -> 0\n  ring_buffer_attach(event, NULL)\n  ring_buffer_put() -> frees the *new* rb\n\nThe revival's refcount_set(&event->mmap_count, 1) is an invisible\n1 -> 1 write: the close frees the just-revived buffer although the\nother process still has it mapped -- a page-level use-after-free\nallowing local privilege escalation to root by any unprivileged user\n(default kernel.perf_event_paranoid=2).\n\nSwap the order of the two counter updates: event->mmap_count is\ndropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0\ntransition and the ring_buffer_attach() stay serialized with\nperf_mmap(). rb->mmap_count == 0 then implies every event using the\nbuffer is detached already, so the result of the rb->mmap_count drop\ncan gate the remaining teardown directly and detach_rest is no longer\nneeded.\n\nAn earlier fix for this race from Kyle Zeng and David Lee takes\nevent->mmap_mutex around both counter updates [0]; here the not-last\nclose stays lockless.","cvssScore":7.8,"cvssSeverity":"HIGH","cvssVector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","cwes":[],"vendors":[],"products":[],"references":[{"url":"https://git.kernel.org/stable/c/0c739f54f1c77f3a4643160cd2e031b6c2f2aab6","tags":[]},{"url":"https://git.kernel.org/stable/c/58a8108bc73de0740d5b88150465d6690ea5f85f","tags":[]},{"url":"https://git.kernel.org/stable/c/929cb3b9dc818dd9fa89d510d4ff2b255e42badd","tags":[]}],"exploitRefs":[],"hasPoc":false,"ai":null}