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 while another process still has it mapped, allowing a local user to access freed kernel memory that can be manipulated to gain root privileges, especially when 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 EPSS score is reported as less than 1%, indicating a very low but non‑zero probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. The absence of a public CVSS score means the severity cannot be quantified, yet the nature of the bug—a local use‑after‑free that can lead to privilege escalation—merits high risk. Exploitation requires a local, unprivileged process to coordinate concurrent mmap and munmap calls and is most likely to be carried out from a compromised user account.

Generated by OpenCVE AI on September 16, 2026 at 14:49 UTC.

Remediation

No vendor fix or workaround currently provided.

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 16, 2026 at 14:49 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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-16T17:00:08Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

  • CWE-416

    Use After Free