Re: [PATCH bpf-next v7 02/10] bpf: Add helpers to describe the R0:R2 return register pair

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2026-08-19 at 08:50 -0700, Yonghong Song wrote:

...

> > > +static int bpf_compute_subprog_ret_regs(struct bpf_verifier_env *env)
> > > +{
> > > +	const struct btf *btf = env->prog->aux->btf;
> > > +	const struct btf_type *type;
> > > +	int subprog;
> > > +	u32 size;
> > > +
> > > +	if (!env->prog->jit_requested || bpf_prog_is_offloaded(env->prog->aux))
> > > +		return 0;
> > > +
> > > +	/*
> > > +	 * Skip the main program: its return value is the program's exit code,
> > > +	 * read out of R0, so it never uses the register pair. An extension does
> > > +	 * have a real prototype for subprog 0, but bpf_check_attach_target()
> > > +	 * refuses to replace a function returning more than 8 bytes.
> > > +	 */
> > > +	for (subprog = 1; subprog < env->subprog_cnt; subprog++) {
> > [Severity: High]
> > Does this code mishandle extension programs (BPF_PROG_TYPE_EXT)?
> > 
> > The comment mentions that bpf_check_attach_target() refuses to replace a
> > function returning more than 8 bytes. However, for extension programs,
> > prog->expected_attach_type is 0, so attach_uses_trampoline_retval(0) evaluates
> > to false, bypassing the size check.
> > 
> > If an extension program successfully attaches and replaces a subprogram
> > returning an __int128 (16 bytes), skipping subprog 0 here means ret_reg_pair
> > won't be set. Could this result in the verifier failing to enforce the
> > initialization of R2, potentially leaking uninitialized register contents to
> > the caller?
> 
> But the comment needs update for this version.
>     bpf_check_attach_target() -> btf_check_func_type_match()

Fixed while applying.