Linux kernel perf/core: a failed perf_mmap() still runs event_mapped, leaking the rdpmc reference count

Impact

When perf_mmap() fails to allocate its buffer it still invoked the event's event_mapped() callback. On x86 that increments the perf_rdpmc_allowed reference counter, and because perf_mmap_close() is never reached in the failure case nothing ever decrements it - another reference-count leak. The practical consequence on an x86 GPU node is that user-space rdpmc stays enabled after the condition that was supposed to gate it has gone away, and the counter itself is permanently skewed; a local user who can force allocation failures can hold that state open. This is a distinct mechanism from the mapping-split leak fixed in the same perf release cycle, with its own commits, so it is tracked separately. The fix returns early on failure.

Who can reach it

Local user who can open a perf event and attempt to mmap its buffer, and can drive the allocation to fail (memory pressure or an oversized request). Reachable wherever perf_event_paranoid lets unprivileged users open events; no remote path.

What to do

Update to a stable kernel with the early-return fix and reboot each node - core perf code, so no module reload or runtime toggle applies. Interim mitigation is to tighten perf_event_paranoid on nodes that do not need unprivileged profiling. The record links only the upstream commits; no vendor advisory with a fixed version is present.

References

Related entries

• Linux kernel RDMA/hns: reserved QP destroyed twice on error paths, corrupting a kernel listCVE-2025-38582 · Linux kernel RDMA/hns (rsv_qp double destruction in free_mr init/exit)High
• Linux kernel (drivers/iommu/intel): VT-d tore the device off the I/O page-fault queue before the hardware had stoppedCVE-2025-38594 · Linux kernel (drivers/iommu/intel)High
• Linux kernel Xen gntdev: dma-buf export installs the fd before setup, giving a use-after-freeCVE-2025-38595 · Linux kernel Xen gntdev (dmabuf_exp_from_pages fd_install ordering)High
• Linux kernel (net/tls): KTLS assumes it owns the TCP receive queue. When another reader drains bytes first, the oldCVE-2025-38616 · Linux kernel (net/tls)High
• Linux kernel (net/xfrm): If the task is preempted onto another CPU during SA lookup, a hit in the per-CPU state cacheCVE-2025-38675 · Linux kernel (net/xfrm)High
• Linux kernel AMD IOMMU: one-byte stack buffer overflow parsing an oversized IVRS cmdline optionCVE-2025-38676 · Linux kernel iommu/amd (ivrs_acpihid kernel command line parsing)High