Re: [PATCH bpf-next v4 2/8] bpf: Record raw memory arguments during argument checking

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2026-09-18 at 06:35 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 6c6b8d8520cdf..1d5e4ee64fc00 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> 
> [ ... ]
> 
> > @@ -7215,7 +7215,8 @@ static int check_mem_size_reg(struct bpf_verifier_env *env,
> >  	 * raw mode so that the program is required to initialize all
> >  	 * the memory that the helper could just partially fill up.
> >  	 */
> > -	if (!tnum_is_const(size_reg->var_off))
> > +	if (!tnum_is_const(size_reg->var_off) &&
> > +	    meta->arg_raw_mem.regno == reg_from_argno(mem_argno))
> >  		meta->arg_raw_mem.regno = 0;
> 
> This isn't a bug, but would it help to say which helpers this actually
> changes (bpf_strtol/bpf_strtoul/bpf_kallsyms_lookup_name, where the
> unrelated variable-length input is checked before the output is recorded)
> and that the effect is to stop withdrawing raw mode from their output
> buffer?
> 
> The commit message states that an unrelated memory argument must not
> discard the output's identity after its initialization size has been
> recorded. Scanning the existing helper protos, the three that have both
> an unrelated variable-size pair and a MEM_UNINIT output all place the
> variable-size input before the output:
> 
>   bpf_strtol_proto / bpf_strtoul_proto (kernel/bpf/helpers.c)
>   bpf_kallsyms_lookup_name_proto (kernel/bpf/syscall.c)
>     .arg1_type = ARG_PTR_TO_MEM | MEM_RDONLY,
>     .arg2_type = ARG_MEM_SIZE[_OR_ZERO],
>     .arg4_type = ARG_PTR_TO_FIXED_SIZE_MEM | MEM_UNINIT | ...
> 
> So the observable effect today is the opposite ordering: a variable
> buf_len / name_sz no longer withdraws raw mode from the arg4 output
> buffer.

Extending the commit message might make sense.

> [ ... ]
> 
> > @@ -8929,6 +8930,11 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg, u32 slot, u32 p
> >  	if (err)
> >  		return err;
> > 
> > +	if (!meta->btf && (arg_type & MEM_UNINIT) &&
> > +	    (base_type(arg_type) == ARG_PTR_TO_MEM ||
> > +	     base_type(arg_type) == ARG_PTR_TO_MAP_VALUE))
> > +		meta->arg_raw_mem.regno = slot + 1;
> 
> This isn't a bug, but could this reuse arg_type_is_raw_mem() (defined at
> verifier.c:8155) so the recording site and check_raw_mode_ok() share one
> definition of a raw memory argument, or are the two predicates meant to
> diverge later in the series?
> 
> The new predicate is term-for-term the body of arg_type_is_raw_mem():
> 
>   static bool arg_type_is_raw_mem(enum bpf_arg_type type)
>   {
>       return (base_type(type) == ARG_PTR_TO_MEM ||
>               base_type(type) == ARG_PTR_TO_MAP_VALUE) &&
>              type & MEM_UNINIT;
>   }
> 
> which is still used by check_raw_mode_ok().

Let's indeed reuse the helper.

...