Re: [RFC][PATCH v2] perf: Fix perf_addr_filters_afjust()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Synchronous freeing of `event->addr_filter_ranges` leads to Use-After-Free during RCU traversal of remote child events.
--

commit 799a469d82e3e73dd73373d7ff11de097bcf39a2
Author: Peter Zijlstra <peterz@infradead.org>

perf: Fix perf_addr_filters_afjust()

Adjusts the lock order and iteration logic for perf_addr_filters_adjust()
to safely handle remote events under RCU. It iterates over the child_list
to find inherited events across threads and uses ctx->lock for
synchronization.

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 00e6dcb931d96..1918a301f23f0 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c

[ ... ]

> @@ -9902,21 +9903,15 @@ static bool perf_addr_filter_vma_adjust(struct perf_addr_filter *filter,
[ ... ]
> +static int __perf_event_addr_filters_adjust(struct perf_event *event,
> +					    struct vm_area_struct *vma)
>  {
>  	struct perf_addr_filters_head *ifh = perf_event_addr_filters(event);
>  	unsigned int restart = 0, count = 0;
> +	struct perf_addr_filter *filter;
>  
> +	guard(raw_spinlock)(&ifh->lock);
>  
>  	list_for_each_entry(filter, &ifh->list, entry) {
>  		if (perf_addr_filter_vma_adjust(filter, vma,
>  						&event->addr_filter_ranges[count]))
>  			restart++;
>  
>  		count++;
>  	}
[ ... ]
> +static void __perf_addr_filters_adjust(struct perf_event *event, void *data)
> +{
> +	struct perf_event *child, *parent = event->parent ?: event;
> +	struct vm_area_struct *vma = data;
[ ... ]
> +	perf_event_addr_filters_adjust(parent, vma);
> +	list_for_each_entry_rcu(child, &parent->child_list, child_list)
> +		perf_event_addr_filters_adjust(child, vma);
> +}

[Severity: High]
This is a pre-existing issue, but does this new RCU traversal of remote child
events expose a use-after-free on event->addr_filter_ranges?

If a child event concurrently exits, it is removed from the list in
perf_child_detach() via list_del_rcu(&event->child_list). Its release process
ultimately calls __free_event(), which synchronously frees the array:

kernel/events/core.c:__free_event() {
        ...
        kfree(event->addr_filter_ranges);
        ...
}

Because this kfree() happens synchronously before the RCU grace period elapses,
the array memory is immediately returned to the allocator.

Meanwhile, the mmap thread running __perf_addr_filters_adjust() under
guard(rcu)() can still safely find and dereference the child event, but it
proceeds to call __perf_event_addr_filters_adjust() and writes directly into
the already freed event->addr_filter_ranges array.

Could this synchronous kfree() in __free_event() result in memory corruption
when perf_addr_filter_vma_adjust() modifies the array during this RCU walk?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623091426.GF49529@noisy.programming.kicks-ass.net?part=1