From: Qing Wang <wangqing7171@gmail.com>
To: peterz@infradead.org
Cc: acme@kernel.org, adrian.hunter@intel.com,
alexander.shishkin@linux.intel.com, irogers@google.com,
james.clark@linaro.org, jolsa@kernel.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
mark.rutland@arm.com, mingo@redhat.com, namhyung@kernel.org,
syzbot+196a82fd904572696b3c@syzkaller.appspotmail.com,
wangqing7171@gmail.com, yuhaocheng035@gmail.com
Subject: Re: [PATCH v3] perf/core: Fix refcount bug and potential UAF in perf_mmap
Date: Thu, 26 Mar 2026 11:18:06 +0800 [thread overview]
Message-ID: <20260326031806.876931-1-wangqing7171@gmail.com> (raw)
In-Reply-To: <20260325151735.GI3738010@noisy.programming.kicks-ass.net>
On Wed, 25 Mar 2026 at 23:17, Peter Zijlstra <peterz@infradead.org> wrote:
> Argh,. why is this hidden in this old thread :/
>
> On Wed, Mar 25, 2026 at 06:20:53PM +0800, yuhaocheng035@gmail.com wrote:
>
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 2c35acc2722b..a3228c587de1 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -6730,9 +6730,10 @@ static void perf_pmu_output_stop(struct perf_event *event);
> > * the buffer here, where we still have a VM context. This means we need
> > * to detach all events redirecting to us.
> > */
> > -static void perf_mmap_close(struct vm_area_struct *vma)
> > +static void __perf_mmap_close(struct vm_area_struct *vma, struct perf_event *event,
> > + bool holds_event_mmap_lock)
> > {
> > - struct perf_event *event = vma->vm_file->private_data;
> > + struct perf_event *iter_event;
> > mapped_f unmapped = get_mapped(event, event_unmapped);
> > struct perf_buffer *rb = ring_buffer_get(event);
> > struct user_struct *mmap_user = rb->mmap_user;
> > @@ -6772,11 +6773,14 @@ static void perf_mmap_close(struct vm_area_struct *vma)
> > if (refcount_dec_and_test(&rb->mmap_count))
> > detach_rest = true;
> >
> > - if (!refcount_dec_and_mutex_lock(&event->mmap_count, &event->mmap_mutex))
> > + if ((!holds_event_mmap_lock &&
> > + !refcount_dec_and_mutex_lock(&event->mmap_count, &event->mmap_mutex)) ||
> > + (holds_event_mmap_lock && !refcount_dec_and_test(&event->mmap_count)))
> > goto out_put;
>
> *groan*, this is horrible.
>
> Let me have a poke to see if there isn't a saner variant around.
I think it's ok to move perf_mmap_close() outside the mutex lock, like this:
https://lore.kernel.org/all/20260325153240.GK3739106@noisy.programming.kicks-ass.net/T/#m0f82e8ecdfdfce4acd5121bcb799e864cf05ebf9
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1f5699b339ec..e5ce03ce926d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7485,9 +7485,12 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma)
*/
ret = map_range(event->rb, vma);
if (ret)
- perf_mmap_close(vma);
+ goto out_close;
}
+ return 0;
+out_close:
+ perf_mmap_close(vma);
return ret;
}
How do you think?
--
Qing
next prev parent reply other threads:[~2026-03-26 3:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 8:25 [PATCH] perf: Fix deadlock in perf_mmap() Qing Wang
2026-03-09 18:59 ` Ian Rogers
2026-03-10 3:37 ` Qing Wang
2026-03-10 4:45 ` Ian Rogers
2026-03-24 18:38 ` Ian Rogers
2026-03-25 6:58 ` Haocheng Yu
2026-03-25 10:20 ` [PATCH v3] perf/core: Fix refcount bug and potential UAF in perf_mmap yuhaocheng035
2026-03-25 15:08 ` Ian Rogers
2026-03-25 15:17 ` Peter Zijlstra
2026-03-25 15:32 ` Peter Zijlstra
2026-03-26 3:18 ` Qing Wang [this message]
2026-03-26 11:28 ` Peter Zijlstra
2026-03-27 12:29 ` [PATCH v4] " yuhaocheng035
2026-03-27 12:31 ` Haocheng Yu
2026-03-27 12:34 ` Peter Zijlstra
2026-05-05 10:50 ` [tip: perf/core] perf/core: Fix deadlock in perf_mmap() failure path tip-bot2 for Peter Zijlstra
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=20260326031806.876931-1-wangqing7171@gmail.com \
--to=wangqing7171@gmail.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=syzbot+196a82fd904572696b3c@syzkaller.appspotmail.com \
--cc=yuhaocheng035@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.