Re: [PATCH 6.12.y v2 2/2] bpf: Invalidate dynptr clones in every call frame on release

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] User-triggerable WARN_ON_ONCE in verifier via cross-frame dynptr release in callbacks, leading to local DoS.
--

commit 47e1f4599f52a8453ee0613fbb7c12af9d40d361
Author: Amery Hung <ameryhung@gmail.com>

bpf: Invalidate dynptr clones in every call frame on release

This patch modifies dynptr release handling to invalidate clones across all
call frames instead of only the submitting pointer's frame. It fixes an
issue where a caller's dynptr slot would not be cleared if a clone was
released in a subprogram.

Link: https://lore.kernel.org/r/20260529014936.2811085-6-ameryhung@gmail.com

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 5d0874a09a8db..9f314360551f8 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -841,22 +841,31 @@ static int unmark_stack_slots_dynptr(struct bpf_verifier_env *env, struct bpf_re
>  	WARN_ON_ONCE(release_reference(env, ref_obj_id));

[Severity: High]
This is a pre-existing issue, but can an unprivileged user trigger this
warning intentionally by releasing a caller's reference from within a
callback?

If a program acquires a refcounted dynptr in a caller frame, passes a
pointer to it into a synchronous callback (such as via a bpf_loop context),
and calls a release helper like bpf_ringbuf_submit_dynptr() from inside
the callback, the initial helper validation succeeds since the dynptr is
valid on the caller's stack. This subsequently invokes
unmark_stack_slots_dynptr().

However, release_reference() calls release_reference_state(), which explicitly
checks if it is inside a callback trying to release a caller's reference.
Since callbacks cannot release caller references, it correctly fails and
returns -EINVAL.

This predictable -EINVAL return unconditionally triggers the WARN_ON_ONCE.
If panic_on_warn is enabled, could this allow a local user to intentionally
crash the kernel during program verification?

>  	invalidate_slices_of_dynptr(env, state->stack[spi].spilled_ptr.id);
>  
> -	/* Invalidate any dynptr clones */
> -	for (i = 1; i < state->allocated_stack / BPF_REG_SIZE; i++) {
> -		if (state->stack[i].spilled_ptr.ref_obj_id != ref_obj_id)
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829033725.2365697-1-xyx2021@mail.ustc.edu.cn?part=2