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.
Published: 2026-09-16
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Local Privilege Escalation via use‑after‑free in perf mmap
Action: Apply Patch
AI Analysis

Impact

The Linux kernel’s perf subsystem has a race condition between its mmap and munmap operations. A concurrent reviving mmap call can overlap with the final munmap of a ring buffer. The resulting use‑after‑free frees a buffer that another process still has mapped, allowing a local user to access freed kernel memory and manipulate it to gain root privileges, especially when kernel.perf_event_paranoid is set to 2.

Affected Systems

This flaw affects all Linux kernel releases that include the perf subsystem prior to the commit that reordered the reference‑count updates. Affected versions are not enumerated by the CNA, but any mainline kernel that has not yet applied the described patch is potentially impacted.

Risk and Exploitability

The CVSS score of 7.8 reflects a high severity local privilege escalation vulnerability. The EPSS score of <1% indicates a very low but non‑zero likelihood that the flaw will be actively exploited in the wild. The vulnerability is not listed in the CISA KEV catalog, so no known exploits are currently catalogued. Exploitation requires a local, unprivileged user on a Linux system that can coordinate concurrent perf mmap and munmap operations on a shared ring buffer. By creating a race between perf_mmap() and perf_mmap_close(), an attacker can trigger a use‑after‑free that frees a ring buffer that another process still holds, allowing access to freed kernel memory and exploitation for root privileges when kernel.perf_event_paranoid is set to 2.

Generated by OpenCVE AI on September 20, 2026 at 04:36 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Install a Linux kernel version that incorporates the perf use‑after‑free fix.
  • If a distribution update is not available, apply the patch from the git commit that reorders the ring buffer reference‑count updates or backport it to the current kernel.
  • Configure the kernel to restrict unprivileged access to perf events, for example by setting kernel.perf_event_paranoid to a higher value, until the patch is applied.

Generated by OpenCVE AI on September 20, 2026 at 04:36 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 18 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 16 Sep 2026 15:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Wed, 16 Sep 2026 09:00:00 +0000

Type Values Removed Values Added
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.
Title perf: Fix use-after-free when perf mmap() revival races with the last munmap()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T14:38:40.190Z

Reserved: 2026-09-11T19:38:34.766Z

Link: CVE-2026-89791

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T09:17:09.930

Modified: 2026-09-16T15:18:09.253

Link: CVE-2026-89791

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T04:45:16Z

Weaknesses

No weakness.