CVE-2026-89791

Status: UPDATED  |  Advisory ID: CVE-2026-89791

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References