Re: [PATCH bpf-next 26/36] bpf: avoid widening registers that hinder exact stack-slot tracking

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: bpf_needs_fixed_stack_off misses dynptr consumers, rejecting valid loops
--

commit a3ca958d64fafcbcf31deb9929c54958bdb72868
Author: Eduard Zingerman <eddyz87@gmail.com>

bpf: avoid widening registers that hinder exact stack-slot tracking

This commit adds logic to prevent loop-widening for registers that are
used as base addresses for stack access instructions that require exact
tracking (such as spills, fills, and calls constructing stack objects).

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 9f56ffe09ebac..327bfc00da5f5 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -14087,6 +14087,46 @@ static bool kfunc_spin_allowed(struct bpf_verifier_env *env, s32 func_id, s16 of
[ ... ]
> +bool bpf_needs_fixed_stack_off(struct bpf_verifier_env *env, int insn_idx)
> +{
> +	const struct bpf_insn *insn = &env->prog->insnsi[insn_idx];
> +	u32 *flags, btf_id;
> +
> +	if (bpf_helper_call(insn)) {
> +		return insn->imm == BPF_FUNC_dynptr_from_mem ||
> +		       insn->imm == BPF_FUNC_ringbuf_reserve_dynptr;
> +	}

[Severity: Medium]
Does this logic miss helper functions that consume dynptrs (like
BPF_FUNC_dynptr_read, BPF_FUNC_dynptr_write, or BPF_FUNC_ringbuf_submit_dynptr)?

Since process_dynptr_func() relies on dynptr_get_spi(), which in turn
requires constant stack offsets via stack_slot_obj_get_spi(), wouldn't
omitting these dynptr consumers here cause a regression? If the verifier
widens the loop variable used for a dynptr array index, the stack offset
becomes non-constant and the verifier will erroneously reject valid programs
that read or write stack-based dynptrs in a loop.

> +
> +	/* vmlinux kfuncs only */
> +	if (!bpf_pseudo_kfunc_call(insn) || insn->off != 0)
> +		return false;
> +	btf_id = insn->imm;
[ ... ]
> +	if (btf_id == special_kfunc_list[KF_bpf_dynptr_from_skb] ||
> +	    btf_id == special_kfunc_list[KF_bpf_dynptr_from_xdp] ||
> +	    btf_id == special_kfunc_list[KF_bpf_dynptr_from_skb_meta] ||
> +	    btf_id == special_kfunc_list[KF_bpf_dynptr_from_file])
> +		return true;

[Severity: Medium]
Similarly, does this miss kfuncs that consume or clone dynptrs (such as
KF_bpf_dynptr_clone and KF_bpf_dynptr_slice)?

If a loop variable is used to compute a dynptr address passed to these
kfuncs, the loop variable will be widened, leading to the same verification
regression when stack_slot_obj_get_spi() is called with a non-constant stack
offset.

> +
> +	return false;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-scev-minimal-rebase-v1-0-c8e5ab5ba79f@gmail.com?part=26