Re: [PATCH 6.12.y v4 2/3] bpf: Propagate referenced dynptr release errors

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] A BPF callback can trigger a kernel panic via WARN_ON_ONCE by destroying a caller-acquired iterator, bypassing verifier boundary checks.
- [High] A BPF callback performing a NULL check on a caller-acquired PTR_MAYBE_NULL reference triggers a kernel panic via WARN_ON_ONCE.
--

commit d4b9f8473b6b567b88014154d968c1bc465a559e
Author: Xu Yunxiang <xyx2021@mail.ustc.edu.cn>
bpf: Propagate referenced dynptr release errors

This commit propagates release_reference() errors in
unmark_stack_slots_dynptr() instead of wrapping them in a WARN_ON_ONCE().
This prevents kernel panics from BPF callbacks trying to release
caller-acquired dynptrs.

Closes: https://lore.kernel.org/r/20260829040110.D6A991F000E9@smtp.kernel.org

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index dbc9cfcffcd60..65ee9afaa5ff0 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -838,7 +838,9 @@ static int unmark_stack_slots_dynptr(struct bpf_verifier_env *env, struct bpf_re
>  	 * Mirror destroy_if_dynptr_stack_slot(), which already invalidates
>  	 * slices by dynptr_id.
>  	 */
> -	WARN_ON_ONCE(release_reference(env, ref_obj_id));
> +	err = release_reference(env, ref_obj_id);
> +	if (err)
> +		return err;
>  	invalidate_slices_of_dynptr(env, state->stack[spi].spilled_ptr.id);

[Severity: High]
This isn't a bug introduced by this patch, but does unmark_stack_slots_iter()
have the exact same problem?

kernel/bpf/verifier.c:unmark_stack_slots_iter() {
...
		if (i == 0)
			WARN_ON_ONCE(release_reference(env, st->ref_obj_id));
...
}

If a caller frame initializes an iterator on its stack and passes a pointer
to this stack slot as the ctx argument to a bpf_loop callback, and the
callback calls bpf_iter_num_destroy(), could the verifier panic the kernel
via this WARN_ON_ONCE (assuming panic_on_warn=1)? 

Since release_reference() would return -EINVAL for a caller's reference,
it seems it would trigger the warning.

[Severity: High]
This is a pre-existing issue, but does mark_ptr_or_null_regs() also need to
handle cross-frame reference errors instead of warning?

kernel/bpf/verifier.c:mark_ptr_or_null_regs() {
...
	if (ref_obj_id && ref_obj_id == id && is_null)
		/* regs[regno] is in the " == NULL" branch.
		 * No one could have freed the reference state before
		 * doing the NULL check.
		 */
		WARN_ON_ONCE(release_reference_state(state, id));
...
}

If a caller acquires a PTR_MAYBE_NULL reference, spills it, and passes a
pointer to it to a bpf_loop callback, and the callback reads the pointer
and performs a NULL check, would release_reference_state() refuse to release
the caller's reference and return -EINVAL? 

If so, this could also trigger the WARN_ON_ONCE and panic the kernel.

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