[PATCH 0/2] perf/core: fix perf_mmap alias charging and the redirected-event AUX mmap

[Joshua Warren]

Two perf mmap() fixes in kernel/events/core.c.  Both defects are
present on torvalds/linux master 05441d697f7f9a927264f4058cbbc6a03dfcac9d,
the tree this series is based on.

Patch 1 stops duplicate alias mmaps of the ring buffer and of the AUX
area from charging the perf mlock gift (user->perf_mlock) twice: the
charge is taken once, at first allocation, and released once at final
close.  The excess was never removed, and perf_mmap_calc_limits()
clamps the recorded perf_mlock at the budget, so an inflated counter
pushes later allocations over into the RLIMIT_MEMLOCK side of the
accounting.

Patch 2 handles the first AUX mmap of a redirected event
(perf_event_set_output()): perf_mmap_aux() refcount_inc()s the event's
mmap_count from zero, which saturates the count and reports
REFCOUNT_ADD_UAF through REFCOUNT_CORRUPTION() (a WARN_ONCE(), or a
BUG() with CONFIG_BUG_ON_DATA_CORRUPTION=y).  A saturated count is
never released: a later AUX mmap() reports REFCOUNT_ADD_OVF once, while
perf_mmap_close() takes the saturated count silently and therefore
never detaches the event from the borrowed rb.  The AUX mmap
of a not-yet-mmaped event is now rejected with -EBUSY, matching the
ring mmap() stance.  The ring-side fix was
commit d06bf78e55d5 ("perf: Fix refcount warning on event->mmap_count
increment").

That is an observable behavior change: the first AUX mmap() of a
redirected event now fails with -EBUSY where it previously reported a
refcount error and saturated the event's mmap_count.  Only flows that
are already broken on this base are affected.

The patch 2 defect is availability only: the count saturates fail-safe,
and no use-after-free was found.  It is reachable by an unprivileged
user through perf_event_set_output() (PERF_FLAG_FD_OUTPUT) on AUX-capable
PMUs where userspace can create the AUX-owning event.  On a default
kernel the first such mmap() prints one warning; with panic_on_warn=1
that first warning panics the kernel, and with
CONFIG_BUG_ON_DATA_CORRUPTION=y the BUG() oopses the task regardless of
panic_on_warn.  The ring-side twin was fixed the same way.

Validation used source-level host harnesses that compile perf_mmap,
perf_mmap_rb, perf_mmap_aux, perf_mmap_close,
perf_mmap_account/unaccount/calc_limits straight from the tree and
drive full single-user, single-mm, single-thread lifecycles over them;
nothing runs in a kernel, and no runtime kernel reproduction was
performed:

- 22-case mmap-charge harness: the base fails 13 (per-alias
  user->perf_mlock charge leak), patch 1 alone passes 22/22, the series
  keeps 22/22 passing.
- redirect-lifecycle harness (33 scenarios): the base fails 22, patch 1
  alone fails exactly the 9 redirected-AUX scenarios (the redirected
  AUX mmap saturates mmap_count), the series passes 33/33.

The harnesses are tooling, not part of these changes.  The series is
compile-verified with a focused x86-64 defconfig build of
kernel/events/core.o; the kernel was not booted.

Kunwu Chan's "perf/core: add AUX buffer kernel-consumer API" (v2,
9 Oct 2026, <20261009160010.1829642-1-kunwu.chan@xxxxxxxxx>) is not
merged upstream, and its series changes no perf_mmap_rb()/
perf_mmap_aux() alias or mlock accounting line, so it does not overlap
these two fixes; both defects described here remain on the base named
above, with or without that series.

AI coding agents in the omp harness wrote the patches, the reproducer
and the measurements. I read every patch in this series before sending
it.

Joshua Warren (2):
  perf/core: Avoid charging mmap aliases twice
  perf/core: handle first AUX mmap on redirected events

 kernel/events/core.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

-- 
2.39.5