{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-89791", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-89791" ], "published": "2026-09-16T08:46:47Z", "summary": "perf: Fix use-after-free when perf mmap() revival races with the last munmap()", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix use-after-free when perf mmap() revival races with the last munmap()\n\nperf_mmap_close() drops rb->mmap_count *without* holding\nevent->mmap_mutex (the refcount_dec_and_test() right before the\nrefcount_dec_and_mutex_lock() of event->mmap_count). A concurrent\nperf_mmap_rb() can slot its entire \"revival\" path into that window\n(perf_mmap holds event->mmap_mutex for its whole duration, including\nrb_alloc):\n\n munmap side (perf_mmap_close) mmap side (perf_mmap_rb)\n ----------------------------------- --------------------------------\n rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex)\n inc_not_zero(rb->mmap_count) fails\n ring_buffer_attach(event, NULL)\n rb_alloc() + attach new rb\n refcount_set(&event->mmap_count, 1)\n lock; event->mmap_count 1 -> 0\n ring_buffer_attach(event, NULL)\n ring_buffer_put() -> frees the *new* rb\n\nThe revival's refcount_set(&event->mmap_count, 1) is an invisible\n1 -> 1 write: the close frees the just-revived buffer although the\nother process still has it mapped -- a page-level use-after-free\nallowing local privilege escalation to root by any unprivileged user\n(default kernel.perf_event_paranoid=2).\n\nSwap the order of the two counter updates: event->mmap_count is\ndropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0\ntransition and the ring_buffer_attach() stay serialized with\nperf_mmap(). rb->mmap_count == 0 then implies every event using the\nbuffer is detached already, so the result of the rb->mmap_count drop\ncan gate the remaining teardown directly and detach_rest is no longer\nneeded.\n\nAn earlier fix for this race from Kyle Zeng and David Lee takes\nevent->mmap_mutex around both counter updates [0]; here the not-last\nclose stays lockless.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1", "1:6.18.50-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-2712", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v6", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v7", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8-rt", "binary_version": "1:6.18.50-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.50-1+rpt1": { "linux_commit": "cff533aec2fa601846766b32ff57204e0a61bed7", "upstream_version": "6.18.50", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-89791" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/929cb3b9dc818dd9fa89d510d4ff2b255e42badd" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0c739f54f1c77f3a4643160cd2e031b6c2f2aab6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/58a8108bc73de0740d5b88150465d6690ea5f85f" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-16T14:40:32Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The UAF is reached only via local syscalls: perf_event_open(2) then mmap(2)/munmap(2) on the resulting perf fd (perf_fops.mmap \u2192 perf_mmap \u2192 perf_mmap_rb racing perf_mmap_close). There is no network, adjacent-radio, or physical path into the ring-buffer revival race.\nAC:L - The attacker drives both sides from threads or processes sharing the fd: one munmap() runs perf_mmap_close() while a concurrent mmap() holds event->mmap_mutex through rb_alloc() and map_range(). That is an attacker-controlled, freely retryable race, not an uninfluenced layout or victim-state condition.\nPR:L - Default kernel.perf_event_paranoid=2 still allows an unprivileged per-task software event with exclude_kernel set; perf_mmap() only calls the optional LSM security_perf_event_read hook and does not require CAP_PERFMON or CAP_SYS_ADMIN. The fix notes local privilege escalation by any unprivileged user.\nUI:N - The attacker opens the event and races mmap/munmap on that fd in their own process or a helper that inherited the fd. No victim action such as mounting a filesystem or opening a file is required.\nS:U - Impact is host-kernel page use-after-free of the perf ring buffer, i.e. standard local privilege escalation in the same OS security authority. It is not a KVM/Xen guest-to-host escape or IOMMU/DMA boundary bypass.\nC:H - perf_mmap_close() frees the revived ring-buffer pages (rb_free) while the concurrent mmap's VM_PFNMAP VMA still maps those PFNs. That page-level UAF lets the attacker reclaim the pages and read arbitrary kernel memory through the still-valid mapping.\nI:H - The same still-mapped PFNs remain writable on the user control page (perf_mmap_pfn_mkwrite), so reclaim/spray of the freed pages yields a kernel write primitive. The fix commit describes this as local privilege escalation to root, matching UAF integrity High.\nA:H - Use-after-free of the ring buffer while it remains mapped causes kernel oops or panic on reuse, and the reporters documented a panic reproducer. Any kernel UAF is availability High even without a completed privilege-escalation exploit." } } }