From: Aditya Chillara <aditya.chillara@oss.qualcomm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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>, 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: Fri, 7 Aug 2026 12:24:20 +0530 [thread overview]
Message-ID: <9a965b40-c15d-4802-8d55-aacb9ad33987@oss.qualcomm.com> (raw)
In-Reply-To: <20260806195020.GR48970@noisy.programming.kicks-ass.net>
On 8/7/2026 1:20 AM, Peter Zijlstra wrote:
>
> Finally got to look at this. In principle this seems okay, but while
> staring at it, I had a few questions, see below.
>
> On Tue, Jun 30, 2026 at 12:42:12AM +0530, Aditya Chillara wrote:
>> ---
>> 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);
>> + }
>
> The below code used __event_disable(); and this change is not
> mentioned in the Changelog. Why was this changed?
I should've mentioned this in the Changelog, I'll update it.
In case of __perf_remove_from_context(event, ...) where the event is part of a group
but is not the leader; by the time we get to perf_group_detach():
1. perf_cgroup_event_disable(event, ctx) would have been called
2. The sibling's state may have been set to EXIT/REVOKED/DEAD if not OFF
So we cannot use __event_disable() because it would unconditionally call
1. perf_cgroup_event_disable() that would decrement nr_cgroups twice
2. perf_event_set_state(event, PERF_EVENT_STATE_ERROR) that could bring back
the state from EXIT/REVOKED/DEAD/OFF to ERROR.
In previous code, in case of __perf_remove_from_context(event, ...) where the event
is a leader; __event_disable() was called for siblings unconditionally but I do not
see a reason why the added guards don't hold.
Should we move the guards to __event_disable() instead? That would simplify the code:
static void __event_disable(struct perf_event *event,
struct perf_event_context *ctx,
enum perf_event_state state)
{
event_sched_out(event, ctx);
if (event->state > PERF_EVENT_STATE_OFF)
perf_cgroup_event_disable(event, ctx);
perf_event_set_state(event, min(event->state, state));
}
Also, event_sched_out() in case of pending_disable calls perf_cgroup_event_disable()
and sets the state to OFF, but __event_disable() immediately calls
perf_cgroup_event_disable() again.
>
>> +
>> + 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++;
>
> Here we can do 's/event->group_//'
I'll update this.
>
> Also, this case 'leader != event' we remove one sibling from a group and
> decrement leader->nr_siblings...
>
>> + 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);
>> }
>
> This is the case 'leader == event' (per not being the other case), and
> this we remove all siblings, but then do not set leader->nr_siblings =
> 0, should we ?
Yes, I'll add this.
Thank you,
Aditya
next prev parent reply other threads:[~2026-08-07 6:54 UTC|newest]
Thread overview: 5+ 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
2026-08-06 19:50 ` Peter Zijlstra
2026-08-07 6:54 ` Aditya Chillara [this message]
2026-08-07 8:57 ` 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=9a965b40-c15d-4802-8d55-aacb9ad33987@oss.qualcomm.com \
--to=aditya.chillara@oss.qualcomm.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@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