Linux kernel perf/core: splitting a perf ring-buffer mapping leaks reference counts on the buffer

Impact

perf requires every subsequent mapping of an event's ring buffer or AUX buffer to use the same offset and size, and its reference counting depends on that. Nothing stopped a process from splitting such a mapping with mmap(2), munmap(2) or mremap(2): the split produced extra perf_mmap_open() calls that took references, while the matching perf_mmap_close() calls no longer satisfied the offset and size checks and so did not drop them. The result is leaked reference counts, which means the ring buffer and AUX pages stay pinned for the lifetime of the machine. On a GPU node where profiling is routinely exposed to tenants, a local user can repeatedly leak pinned kernel memory until the node is out of usable RAM - and pinned, un-reclaimable memory is precisely what kills large training jobs. Recovery is a reboot; the leak cannot be reclaimed at runtime. The fix adds a may_split() callback that unconditionally returns -EINVAL.

Who can reach it

Local user who can open a perf event and mmap its buffer - that is, anyone on the node when perf_event_paranoid is relaxed (common on profiling-enabled GPU and HPC nodes) or any user already permitted to profile. No remote path and no special capability beyond perf access.

What to do

Update to a stable kernel carrying the may_split() fix and reboot each node; this is core perf code, not a module, so there is no hot path to it. As an interim mitigation, raise perf_event_paranoid so unprivileged users cannot open perf events on nodes that do not need tenant profiling. Only the upstream commits are present in the record; no advisory names a single fixed version.

References

Related entries

• Linux kernel perf/core: a failed perf_mmap() still runs event_mapped, leaking the rdpmc reference countCVE-2025-38565 · Linux kernel perf/core (perf_mmap() failure path, event_mapped callback and perf_rdpmc_allowed)High
• 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