Re: [PATCH v3] 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] Permanent leak of locked_vm accounting when mmapping the same perf event ring buffer or AUX buffer multiple times.
--

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

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

This commit fixes a use-after-free vulnerability in the perf events subsystem
by swapping the order of counter decrements in perf_mmap_close(). The change
ensures that event->mmap_count is decremented first under the mmap_mutex,
closing a race window where a newly attached ring buffer could be mistakenly
freed.

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..f56f9d9e4f01b 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -7060,17 +7059,14 @@ 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);
> +	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 the early return here leak the
locked_vm accounting when the same perf event ring buffer or AUX buffer is
mmapped multiple times?

Looking at the mmap side in perf_mmap_rb() and perf_mmap_aux(), secondary 
mmaps repeatedly charge the user's locked_vm:

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

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

However, the unaccounting in perf_mmap_close() only happens exactly once when
the last mmap is closed and rb->mmap_count reaches zero:

kernel/events/core.c:perf_mmap_close() {
	...
	if (!refcount_dec_and_test(&rb->mmap_count))
		goto out_put;
	...
	perf_mmap_unaccount(vma, rb);
out_put:
	ring_buffer_put(rb);
}

Because locked_vm is used system-wide to enforce RLIMIT_MEMLOCK (e.g., by
io_uring, BPF, XDP, and secretmem), an attacker could trivially loop calling
mmap() on the same file descriptor to artificially inflate this counter until
the limit is exhausted.

Does this create a persistent Denial of Service for all processes running
under that UID, making the system fully unusable for the affected user's
services until all processes of that user exit?

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