From: "Rafael B. Dias" <rafaelbttdias@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
security@kernel.org
Subject: [PATCH] perf/core: unaccount mmap pages from the charged owners
Date: Wed, 22 Jul 2026 03:03:53 -0300 [thread overview]
Message-ID: <20260722060353.24-1-rafaelbttdias@gmail.com> (raw)
In-Reply-To: <CAFhB66oYbThmK59NiT1YwFZ4z=xkNxj9paga4EJW+mGFHa8f8A@mail.gmail.com>
perf mmap accounting splits pages between user_struct::locked_vm and
mm_struct::pinned_vm. The first mapping that allocates a data ring stores
the charged user and numeric pinned amount in perf_buffer, but it does not
store the mm that received the pinned charge.
A perf event fd can be mapped by more than one process. If a different mm
owns the final VMA close, perf_mmap_unaccount() subtracts mmap_locked from
that final mm instead of the mm charged at allocation. Repeating this
across short-lived donor processes creates a negative pinned_vm balance
that can fund later perf mappings beyond RLIMIT_MEMLOCK.
AUX has the same last-VMA assumption. It also subtracts locked_vm from the
data ring's mmap_user even when a different user created the AUX mapping.
Retain references to the mm charged for the data ring and to the user and
mm charged for AUX. Use those stored owners during final unaccounting and
release the references after the counters are restored.
On a two-CPU 6.12.94 KASAN guest, an unprivileged receiver with
RLIMIT_MEMLOCK=0 accumulated 16,385 pages of cross-mm credit and mapped
65,540 KiB on the vulnerable kernel. The same reproducer returned EPERM
with this ownership fix. No KASAN report or warning occurred. The patch
also builds kernel/events/core.o with x86_64_defconfig on the same base.
Fixes: 26cb63ad11e0 ("perf: Fix perf mmap bugs")
Fixes: 36b3db03b474 ("perf/core: Fix the mlock accounting, again")
Cc: stable@vger.kernel.org
Assisted-by: OpenAI-Codex:gpt-5.6-sol
Signed-off-by: Rafael B. Dias <rafaelbttdias@gmail.com>
---
kernel/events/core.c | 27 +++++++++++++++++++--------
kernel/events/internal.h | 3 +++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index ba5bd6a78fe7..bf046e44de20 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7006,7 +7006,7 @@ static void perf_mmap_open(struct vm_area_struct *vma)
}
static void perf_pmu_output_stop(struct perf_event *event);
-static void perf_mmap_unaccount(struct vm_area_struct *vma, struct perf_buffer *rb);
+static void perf_mmap_unaccount(struct perf_buffer *rb);
/*
* A buffer can be mmap()ed multiple times; either directly through the same
@@ -7021,7 +7021,6 @@ static void perf_mmap_close(struct vm_area_struct *vma)
struct perf_event *event = vma->vm_file->private_data;
mapped_f unmapped = get_mapped(event, event_unmapped);
struct perf_buffer *rb = ring_buffer_get(event);
- struct user_struct *mmap_user = rb->mmap_user;
bool detach_rest = false;
/* FIXIES vs perf_pmu_unregister() */
@@ -7043,8 +7042,13 @@ static void perf_mmap_close(struct vm_area_struct *vma)
perf_pmu_output_stop(event);
/* now it's safe to free the pages */
- atomic_long_sub(rb->aux_nr_pages - rb->aux_mmap_locked, &mmap_user->locked_vm);
- atomic64_sub(rb->aux_mmap_locked, &vma->vm_mm->pinned_vm);
+ atomic_long_sub(rb->aux_nr_pages - rb->aux_mmap_locked,
+ &rb->aux_mmap_user->locked_vm);
+ atomic64_sub(rb->aux_mmap_locked, &rb->aux_mmap_mm->pinned_vm);
+ free_uid(rb->aux_mmap_user);
+ mmdrop(rb->aux_mmap_mm);
+ rb->aux_mmap_user = NULL;
+ rb->aux_mmap_mm = NULL;
/* this has to be the last one */
rb_free_aux(rb);
@@ -7116,7 +7120,7 @@ static void perf_mmap_close(struct vm_area_struct *vma)
* Aside from that, this buffer is 'fully' detached and unmapped,
* undo the VM accounting.
*/
- perf_mmap_unaccount(vma, rb);
+ perf_mmap_unaccount(rb);
out_put:
ring_buffer_put(rb); /* could be last */
@@ -7258,13 +7262,15 @@ static void perf_mmap_account(struct vm_area_struct *vma, long user_extra, long
atomic64_add(extra, &vma->vm_mm->pinned_vm);
}
-static void perf_mmap_unaccount(struct vm_area_struct *vma, struct perf_buffer *rb)
+static void perf_mmap_unaccount(struct perf_buffer *rb)
{
struct user_struct *user = rb->mmap_user;
atomic_long_sub((perf_data_size(rb) >> PAGE_SHIFT) + 1 - rb->mmap_locked,
&user->locked_vm);
- atomic64_sub(rb->mmap_locked, &vma->vm_mm->pinned_vm);
+ atomic64_sub(rb->mmap_locked, &rb->mmap_mm->pinned_vm);
+ mmdrop(rb->mmap_mm);
+ rb->mmap_mm = NULL;
}
static int perf_mmap_rb(struct vm_area_struct *vma, struct perf_event *event,
@@ -7330,6 +7336,8 @@ static int perf_mmap_rb(struct vm_area_struct *vma, struct perf_event *event,
return -ENOMEM;
rb->mmap_locked = extra;
+ rb->mmap_mm = vma->vm_mm;
+ mmgrab(rb->mmap_mm);
ring_buffer_attach(event, rb);
@@ -7411,6 +7419,9 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
refcount_set(&rb->aux_mmap_count, 1);
rb->aux_mmap_locked = extra;
+ rb->aux_mmap_user = get_current_user();
+ rb->aux_mmap_mm = vma->vm_mm;
+ mmgrab(rb->aux_mmap_mm);
}
perf_mmap_account(vma, user_extra, extra);
@@ -7512,7 +7523,7 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma)
mapped = get_mapped(event, event_unmapped);
if (mapped)
mapped(event, vma->vm_mm);
- perf_mmap_unaccount(vma, event->rb);
+ perf_mmap_unaccount(event->rb);
ring_buffer_attach(event, NULL); /* drops last rb->refcount */
refcount_set(&event->mmap_count, 0);
return ret;
diff --git a/kernel/events/internal.h b/kernel/events/internal.h
index c03c4f2eea57..9bdf586735e8 100644
--- a/kernel/events/internal.h
+++ b/kernel/events/internal.h
@@ -38,6 +38,7 @@ struct perf_buffer {
refcount_t mmap_count;
unsigned long mmap_locked;
struct user_struct *mmap_user;
+ struct mm_struct *mmap_mm;
/* AUX area */
struct mutex aux_mutex;
@@ -49,6 +50,8 @@ struct perf_buffer {
int aux_overwrite;
refcount_t aux_mmap_count;
unsigned long aux_mmap_locked;
+ struct user_struct *aux_mmap_user;
+ struct mm_struct *aux_mmap_mm;
void (*free_aux)(void *);
refcount_t aux_refcount;
int aux_in_sampling;
prev parent reply other threads:[~2026-07-22 6:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 5:59 [BUG] perf: cross-mm mmap teardown unaccounts pinned memory from the wrong mm Rafael B. Dias
2026-07-22 6:03 ` Rafael B. Dias [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722060353.24-1-rafaelbttdias@gmail.com \
--to=rafaelbttdias@gmail.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=security@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®