> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 7708958e3fb8..ebb1b0c3f993 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c

[ ... ]

> @@ -6905,8 +6920,11 @@ bool btf_ctx_access(int off, int size, enum 
> bpf_access_type type,
>       /*
>        * If it's a pointer to void, it's the same as scalar from the verifier
>        * safety POV. Either way, no futher pointer walking is allowed.
> +      * Multilevel pointers (e.g., int**, struct foo**, char***) of any type
> +      * are treated as scalars because the verifier lacks the context to 
> infer
> +      * the size of their target memory regions.
>        */
> -     if (is_void_or_int_ptr(btf, t))
> +     if (is_void_or_int_ptr(btf, t) || is_multilevel_ptr(btf, t))
>               return true;

In the v2 review thread, Alexei Starovoitov wrote:

  "I'm less certain about 'char **'. If we make it scalar too
   it will be harder to make it a pointer to nul terminated
   string later.

   So I would do 'void **' -> scalar for now only."

https://lore.kernel.org/bpf/caadnvq+xwc+j1hzchpeujbokcukmnucg4afq-kkdmqx+c-g...@mail.gmail.com/

The comment says "of any type" and is_multilevel_ptr() matches all
multi-level pointers (int**, struct foo**, char***), which is broader
than the requested scope. Was the decision to treat all multi-level
pointer types as scalar discussed with Alexei after the v2 feedback?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22298698870

AI-authorship-score: low
AI-authorship-explanation: Code exhibits human-authored characteristics 
including idiomatic kernel C patterns, iterative revision based on reviewer 
feedback across three versions, and deep domain knowledge of BPF verifier 
internals.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: Unaddressed maintainer feedback about limiting 
scope to void** pointers only; the broader approach is functionally safe but 
contradicts the requested design direction.

Reply via email to