From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Aditya Chillara <aditya.chillara@oss.qualcomm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach
Date: Tue, 30 Jun 2026 11:10:49 +0800 [thread overview]
Message-ID: <acea8b54-4887-4d59-9bd9-0fa7ff803d3a@linux.intel.com> (raw)
In-Reply-To: <20260630-fix-group-leader-uaf-v2-1-9349121835ee@oss.qualcomm.com>
LGTM.
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
On 6/30/2026 3:12 AM, Aditya Chillara wrote:
> perf_group_detach() handles leader and sibling detach differently. When the
> group leader is detached, all siblings are promoted to singleton events and
> their group_leader pointer is reset to themselves. When a sibling is
> detached, it is removed from the leader's sibling_list, but its
> group_leader pointer is left pointing at the old leader.
>
> That is harmless when the sibling is being closed and freed immediately, as
> in the DETACH_DEAD path. It is not safe when the sibling is detached but
> kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the
> sibling is removed from the context, while its file descriptor can still
> keep it alive.
>
> A typical failing sequence is:
>
> - A group contains leader L and sibling S.
> - CPU hot-unplug detaches S with DETACH_GROUP, removing it from
> L->sibling_list but leaving S->group_leader == L.
> - L is later closed and freed.
> - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and
> dereferences the freed leader.
>
> This was reproduced by running the perf event fuzzer, CPU hotplug, and a
> stress workload concurrently:
>
> Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb
> CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT
> pc : perf_ioctl+0x34c/0xc68
> x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b
> Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908)
> Call trace:
> perf_ioctl+0x34c/0xc68 (P)
> __arm64_sys_ioctl+0xa0/0xf4
> invoke_syscall+0x58/0xe4
> el0_svc_common+0xa8/0xdc
> do_el0_svc+0x1c/0x28
> el0_svc+0x40/0xc0
> el0t_64_sync_handler+0x68/0xdc
> el0t_64_sync+0x1c4/0x1c8
>
> The fault happened in perf_ioctl(), where perf_event_for_each() follows
> the stale group_leader pointer and perf_event_for_each_child() then
> dereferences the freed leader's context.
>
> Fix the use-after-free by promoting the detached sibling to a singleton.
>
> Fixes: 8a49542c0554 ("perf_events: Fix races in group composition")
> Assisted-by: PatchWise:gpt-5.5
> Signed-off-by: Aditya Chillara <aditya.chillara@oss.qualcomm.com>
> ---
> Changes in v2:
> - Moved the fix to perf_group_detach() with a small refactor
> - Link to v1: https://patch.msgid.link/20260626-fix-group-leader-uaf-v1-1-ac54652ca944@oss.qualcomm.com
> ---
> kernel/events/core.c | 62 +++++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 42 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 954c36e28101..744643ada948 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2253,6 +2253,8 @@ static void put_event(struct perf_event *event);
> static void __event_disable(struct perf_event *event,
> struct perf_event_context *ctx,
> enum perf_event_state state);
> +static void event_sched_out(struct perf_event *event,
> + struct perf_event_context *ctx);
>
> static void perf_put_aux_event(struct perf_event *event)
> {
> @@ -2343,6 +2345,44 @@ static inline struct list_head *get_event_list(struct perf_event *event)
> &event->pmu_ctx->flexible_active;
> }
>
> +/* @sibling must already be unlinked from its old leader's sibling_list. */
> +static void perf_promote_sibling_to_leader(struct perf_event *sibling,
> + struct perf_event_context *ctx,
> + int group_caps)
> +{
> + /*
> + * Events that have PERF_EV_CAP_SIBLING require being part of
> + * a group and cannot exist on their own, schedule them out
> + * and move them into the ERROR state. Also see
> + * _perf_event_enable(), it will not be able to recover this
> + * ERROR state.
> + */
> + if (sibling->event_caps & PERF_EV_CAP_SIBLING) {
> + event_sched_out(sibling, ctx);
> +
> + /*
> + * The guards keep this correct even when @sibling is already
> + * disabled (see __perf_remove_from_context()).
> + */
> + if (sibling->state > PERF_EVENT_STATE_OFF)
> + perf_cgroup_event_disable(sibling, ctx);
> + if (sibling->state > PERF_EVENT_STATE_ERROR)
> + perf_event_set_state(sibling, PERF_EVENT_STATE_ERROR);
> + }
> +
> + sibling->group_leader = sibling;
> + sibling->group_caps = group_caps;
> +
> + if (sibling->attach_state & PERF_ATTACH_CONTEXT) {
> + add_event_to_groups(sibling, ctx);
> +
> + if (sibling->state == PERF_EVENT_STATE_ACTIVE)
> + list_add_tail(&sibling->active_list, get_event_list(sibling));
> + }
> +
> + perf_event__header_size(sibling);
> +}
> +
> static void perf_group_detach(struct perf_event *event)
> {
> struct perf_event *leader = event->group_leader;
> @@ -2368,6 +2408,7 @@ static void perf_group_detach(struct perf_event *event)
> list_del_init(&event->sibling_list);
> event->group_leader->nr_siblings--;
> event->group_leader->group_generation++;
> + perf_promote_sibling_to_leader(event, ctx, event->event_caps);
> goto out;
> }
>
> @@ -2377,29 +2418,10 @@ static void perf_group_detach(struct perf_event *event)
> * to whatever list we are on.
> */
> list_for_each_entry_safe(sibling, tmp, &event->sibling_list, sibling_list) {
> -
> - /*
> - * Events that have PERF_EV_CAP_SIBLING require being part of
> - * a group and cannot exist on their own, schedule them out
> - * and move them into the ERROR state. Also see
> - * _perf_event_enable(), it will not be able to recover this
> - * ERROR state.
> - */
> - if (sibling->event_caps & PERF_EV_CAP_SIBLING)
> - __event_disable(sibling, ctx, PERF_EVENT_STATE_ERROR);
> -
> - sibling->group_leader = sibling;
> list_del_init(&sibling->sibling_list);
>
> /* Inherit group flags from the previous leader */
> - sibling->group_caps = event->group_caps;
> -
> - if (sibling->attach_state & PERF_ATTACH_CONTEXT) {
> - add_event_to_groups(sibling, event->ctx);
> -
> - if (sibling->state == PERF_EVENT_STATE_ACTIVE)
> - list_add_tail(&sibling->active_list, get_event_list(sibling));
> - }
> + perf_promote_sibling_to_leader(sibling, ctx, event->group_caps);
>
> WARN_ON_ONCE(sibling->ctx != event->ctx);
> }
>
> ---
> base-commit: ab9de95c9cf952332ab79453b4b5d1bfca8e514f
> change-id: 20260626-fix-group-leader-uaf-c46960e525e0
>
> Best regards,
> --
> Aditya Chillara <aditya.chillara@oss.qualcomm.com>
>
>
prev parent reply other threads:[~2026-06-30 3:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 19:12 [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach Aditya Chillara
2026-06-30 3:10 ` Mi, Dapeng [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=acea8b54-4887-4d59-9bd9-0fa7ff803d3a@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=aditya.chillara@oss.qualcomm.com \
--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@elte.hu \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=stable@vger.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