Re: [PATCH] perf/core: fix locked_vm leak on alias mmap() and cross-MM pinned_vm underflow

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] perf: mmdrop() in RCU callback causes softirq context violation
--

commit f66e9c8b5f2a9c636e7dc5afd975c9e2ed17cf78
Author: Hui Peng <benquike@gmail.com>

perf/core: fix locked_vm leak on alias mmap() and cross-MM pinned_vm underflow

In perf_mmap(), mapping an output ring buffer onto an event via
PERF_EVENT_IOC_SET_OUTPUT / alias mmap() increments user->locked_vm and
mm->pinned_vm without recording the accounting MM on the ring_buffer or
releasing user_extra onperf_mmap_close(), causing a permanent locked_vm
leak and a cross-MM pinned_vm underflow when the mapping is closed in a
different process. Store the accounted mm_struct on struct perf_buffer
and unaccount against the original mm_struct on close.

> diff --git a/kernel/events/internal.h b/kernel/events/internal.h
> index c03c4f2eea571..f10eacd8b5903 100644
> --- a/kernel/events/internal.h
> +++ b/kernel/events/internal.h
[ ... ]
> @@ -67,6 +70,10 @@ static inline void rb_free_rcu(struct rcu_head *rcu_head)
>  	struct perf_buffer *rb;
>  
>  	rb = container_of(rcu_head, struct perf_buffer, rcu_head);
> +	if (rb->aux_mmap_mm)
> +		mmdrop(rb->aux_mmap_mm);
> +	if (rb->mmap_mm)
> +		mmdrop(rb->mmap_mm);

[Severity: High]
Does this code call mmdrop() in an RCU callback, which executes in a softirq
context?

If this mmdrop() drops the final mm_count reference (for instance, if the
original process has already exited), it synchronously invokes __mmdrop().
__mmdrop() performs blocking teardown operations (such as pgd_free() and
percpu_counter_destroy()) which can sleep.

Sleeping in a softirq context is illegal and leads to a kernel BUG or panic.

This could happen if a process mmaps a perf event to create a ring buffer,
which uses mmgrab() to increment mm_count. If the process then exits, dropping
its own mm reference, and later the ring buffer is unmapped (e.g., by another
process closing the alias), this triggers ring_buffer_put(), which schedules
rb_free_rcu() via call_rcu(). The RCU callback then drops the final reference
and triggers the bug.

Should this teardown be deferred to the workqueue (rb_free_work) which runs
in a process context, or perhaps use mmdrop_async() instead?

>  	free_uid(rb->mmap_user);
>  	rb_free(rb);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919221728.3707189-1-benquike@gmail.com?part=1