---
cve: "CVE-2026-89791"
severity: "HIGH"
cvss: 7.8
epss: "19%"
vendor: "Linux"
kev: false
exploited: false
published: "2026-09-16 09:17:09"
tags: [cve, security, high]
source: tsecurity.de CVE-Dossier
exported: "2026-09-19T21:57:30+02:00"
---

# CVE-2026-89791

> 7.8 HIGH

## Beschreibung

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.

## CVSS-Vektor

```
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
```

| Metrik | Wert | Bewertung |
|---|---|---|
| AV Angriffsvektor | Lokal | good |
| AC Komplexität | Gering | bad |
| PR Privilegien | Gering | warn |
| UI Interaktion | Keine | bad |
| S Scope | Unverändert | good |
| C Vertraulichkeit | Hoch | bad |
| I Integrität | Hoch | bad |
| A Verfügbarkeit | Hoch | bad |

## Patch verfügbar (OSV)

- Kernel ≥ 6.18.52
- Kernel ≥ 7.2.5

## Referenzen

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

---
_Exportiert aus dem [tsecurity.de CVE-Dossier](https://tsecurity.de/cve?cve=CVE-2026-89791) · Datenquellen: EUVD (ENISA), NVD, OSV, CISA KEV, FIRST EPSS, Exploit-DB, BSI BITS_
