Re: [PATCH bpf-next v5 1/2] bpf: Track iterator-owned BTF pointer lifetimes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: Incomplete invalidation of iter-owned dynptrs and derived memory slices
--

commit 1d039be28498ad8b8b6d1373478f0903a6cc5f06
Author: Xu Yunxiang <xyx2021@mail.ustc.edu.cn>

bpf: Track iterator-owned BTF pointer lifetimes

This commit opts specific iterators into tracking the element lifetime,
associating the PTR_TO_BTF_ID results with the iterator reference. It
invalidates the previous result before advancing the iterator or destroying
it.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -7824,6 +7841,27 @@ static bool is_kfunc_arg_iter(struct bpf_call_arg_meta *meta, int arg_idx,
>  	return btf_param_match_suffix(meta->btf, arg, "__iter");
>  }
>  
> +static int invalidate_iter_owned_btf_ptrs(struct bpf_verifier_env *env, u32 parent_id)
> +{
> +	struct bpf_func_state *unused;
> +	struct bpf_reg_state *reg;
> +	int err;
> +
> +	err = check_reference_children_leak(env, parent_id);
> +	if (err)
> +		return err;
> +
> +	/* Opted-in iterators can release their previous element on next. */
> +	bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
> +		if (base_type(reg->type) != PTR_TO_BTF_ID || reg->parent_id != parent_id)
> +			continue;
> +		bpf_diag_record_scrub(env, reg, BPF_DIAG_MOD_REF_RELEASE);
> +		mark_reg_invalid(env, reg);
> +	}));

[Severity: Medium]
Does this loop completely invalidate all derived pointers?

In mark_stack_slots_dynptr(), the lifetime of a dynptr is explicitly tied
to the iter-owned backing object using the parent ID:

/* All non-clone constructors take their backing object in R1. */
parent_id = reg_lifetime_id(env, &cur_regs(env)[BPF_REG_1]);

However, the invalidation logic here restricts its checks to PTR_TO_BTF_ID.
It ignores STACK_DYNPTR slots because bpf_for_each_reg_in_vstate expands
to use a mask of 1 << STACK_SPILL, skipping STACK_DYNPTR entirely.

It also misses PTR_TO_MEM slices because of the strict PTR_TO_BTF_ID
type check.

If a BPF program creates a non-referenced dynptr from an iter-owned object,
or creates a PTR_TO_MEM slice from it, will these pointers remain usable
after the iterator advances and frees the underlying element, leading to a
use-after-free?

> +
> +	return 0;
> +}

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