Linux Perf Users
 help / color / mirror / Atom feed
* [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach
@ 2026-06-29 19:12 Aditya Chillara
  2026-06-30  3:10 ` Mi, Dapeng
  2026-08-06 19:50 ` Peter Zijlstra
  0 siblings, 2 replies; 5+ messages in thread
From: Aditya Chillara @ 2026-06-29 19:12 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
	Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
	Ian Rogers, Adrian Hunter, James Clark
  Cc: Peter Zijlstra, Ingo Molnar, linux-perf-users, linux-kernel,
	stable, Aditya Chillara

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>


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach
  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
  1 sibling, 0 replies; 5+ messages in thread
From: Mi, Dapeng @ 2026-06-30  3:10 UTC (permalink / raw)
  To: Aditya Chillara, Peter Zijlstra, Ingo Molnar,
	Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
	Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
	James Clark
  Cc: Peter Zijlstra, Ingo Molnar, linux-perf-users, linux-kernel,
	stable

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>
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach
  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
  1 sibling, 1 reply; 5+ messages in thread
From: Peter Zijlstra @ 2026-08-06 19:50 UTC (permalink / raw)
  To: Aditya Chillara
  Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
	Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
	James Clark, Ingo Molnar, linux-perf-users, linux-kernel, stable


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?

> +
> +	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_//'

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 ?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach
  2026-08-06 19:50 ` Peter Zijlstra
@ 2026-08-07  6:54   ` Aditya Chillara
  2026-08-07  8:57     ` Peter Zijlstra
  0 siblings, 1 reply; 5+ messages in thread
From: Aditya Chillara @ 2026-08-07  6:54 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
	Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
	James Clark, Ingo Molnar, linux-perf-users, linux-kernel, stable

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] perf/core: Fix group leader use-after-free after sibling detach
  2026-08-07  6:54   ` Aditya Chillara
@ 2026-08-07  8:57     ` Peter Zijlstra
  0 siblings, 0 replies; 5+ messages in thread
From: Peter Zijlstra @ 2026-08-07  8:57 UTC (permalink / raw)
  To: Aditya Chillara
  Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
	Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
	James Clark, Ingo Molnar, linux-perf-users, linux-kernel, stable

On Fri, Aug 07, 2026 at 12:24:20PM +0530, Aditya Chillara wrote:

> > 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));
> }

Yes, that looks good.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-08-07  8:58 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2026-08-07  8:57     ` Peter Zijlstra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox