Homepage

Expired Pointer Dereference The advisory has been revoked - it doesn't affect any version of package rv  (opens in a new tab)

Threat Intelligence

EPSS
0.18% (8th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-RV-20545755
  • published7 Oct 2026
  • disclosed16 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 16 Sep 2026

CVE-2026-89791  (opens in a new tab)
CWE-825  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:10.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rv package and not the rv package as distributed by RHEL.

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.