Fedora Account System
Red Hat Associate
Red Hat Customer
In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix page UAF in map_range() map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are serialized by rb->aux_mutex, and mmap_mutex is per event. Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows: CPU 0 CPU 1 ===== ===== rb_alloc_aux() map_range() [1]: allocate rb->aux_pages[0] [2]: rb->aux_nr_pages++ [3]: perf_mmap_to_page() returns rb->aux_pages[0] [4]: map it as VM_PFNMAP [5]: rb->aux_pgoff = 1 munmap the page [6]: free rb->aux_pages[0] Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame. Fix this by taking rb->aux_mutex across the page walk in map_range().
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2026072506-CVE-2026-64300-c4cc@gregkh/T
Additional exploitability information: STAR Labs reports that CVE-2026-64300 was converted into a reliable local privilege escalation exploit, with a public demonstration video. The exploit was successfully tested on Arch Linux kernel 7.0.12. The researchers state that the vulnerable path is reachable on Intel bare-metal systems with perf_event_paranoid <= 2, and mention RHEL-based distributions as potentially meeting these conditions. No public exploit code appears to be available. Could you please consider this information when assessing the affected RHEL products? STAR Labs article linked in this comment. https://starlabs.sg/blog/2026/07-when-ai-makes-0-days-feel-like-n-days/
This issue has been addressed in the following products: Red Hat Enterprise Linux 10 Via RHSA-2026:54343 https://access.redhat.com/errata/RHSA-2026:54343