Re: [PATCH v4] perf: Fix use-after-free when perf mmap() revival races with the last munmap()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Preexisting memory accounting leak for locked_vm when mmap() is called multiple times on the same perf event (alias mmaps).
--

commit a96fa5a03867a00fbbf2c3b6dd3bf82931c0fdde
Author: Yilin Zhang <yilinzhang@moonshot.ai>

perf: Fix use-after-free when perf mmap() revival races with the last munmap()

This commit swaps the order of counter updates in perf_mmap_close() to fix
a page-level use-after-free. It drops event->mmap_count first, serializing
its 1 -> 0 transition and ring_buffer_attach() with perf_mmap(), preventing
buffer revival after rb->mmap_count reaches zero.

Link: https://lore.kernel.org/linux-perf-users/20260804060931.711308-1-david.lee@trailofbits.com/

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index a6c8e38a31104..f02780529b439 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
[ ... ]
> @@ -7060,17 +7059,18 @@ static void perf_mmap_close(struct vm_area_struct *vma)
>  		mutex_unlock(&rb->aux_mutex);
>  	}
>  
> -	if (refcount_dec_and_test(&rb->mmap_count))
> -		detach_rest = true;
> -
> -	if (!refcount_dec_and_mutex_lock(&event->mmap_count, &event->mmap_mutex))
> -		goto out_put;
> -
> -	ring_buffer_attach(event, NULL);
> -	mutex_unlock(&event->mmap_mutex);
> +	/*
> +	 * Drop references in reverse order of perf_mmap() to prevent
> +	 * rb revival after rb->mmap_count reaches zero.
> +	 */
> +	if (refcount_dec_and_mutex_lock(&event->mmap_count,
> +					&event->mmap_mutex)) {
> +		ring_buffer_attach(event, NULL);
> +		mutex_unlock(&event->mmap_mutex);
> +	}
>  
>  	/* If there's still other mmap()s of this buffer, we're done. */
> -	if (!detach_rest)
> +	if (!refcount_dec_and_test(&rb->mmap_count))
>  		goto out_put;

[Severity: High]
This is a pre-existing issue, but does this goto bypass the unaccounting for
all but the final close?

If an application calls mmap() on the same perf event file descriptor multiple
times, perf_mmap_rb() accounts user_extra to current_user()->locked_vm on
every alias mmap:

kernel/events/core.c:perf_mmap_rb() {
    ...
			perf_mmap_account(vma, user_extra, extra);
			refcount_inc(&event->mmap_count);
			return 0;
    ...
}

When munmap() is called for all of them, perf_mmap_close() only calls
perf_mmap_unaccount() when rb->mmap_count drops to zero, which happens only
once.

Could this permanently leak locked_vm charges on every alias munmap,
potentially exhausting the user's RLIMIT_MEMLOCK quota and causing a Denial
of Service for other subsystems (like BPF or io_uring) relying on it?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831162155.1437652-1-yilinzhang@moonshot.ai?part=1