Re: [PATCH bpf-next 1/6] bpf: Extend BTF UAPI vlen, kinds to use unused bits

Mykyta Yatsenko
2026-04-15T15:48:28Z

On 4/14/26 10:11 PM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 2 potential issue(s):
> - [High] The `env_stack_set_next_member()` helper takes a `u16` argument, which truncates the new 24-bit BTF `vlen` and causes an O(N^2) infinite-loop-like CPU lockup (Denial of Service).
> - [Medium] UAPI Source Breakage: Converting `BTF_MAX_*` macros to `enum btf_max` removes preprocessor macros, breaking existing userspace compilation.
> --
>
> commit d88c0688f1be53ae1871dacf198a4a18b2e56ae0
> Author: Alan Maguire <alan.maguire@oracle.com>
>
> bpf: Extend BTF UAPI vlen, kinds to use unused bits
>
> This commit expands the BTF maximum vlen from 16 bits to 24 bits, allowing
> up to 16 million members. It also extends the BTF kind encoding from 5 to 7
> bits, and converts the BTF_MAX_* constants to an enum to expose them in
> kernel BTF.
>
> Link: https://lore.kernel.org/bpf/CAEf4BzZx=X6vGqcA8SPU6D+v6k+TR=ZewebXMuXtpmML058piw@mail.gmail.com/
>
>> diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
>> index 638615ebddc22..618167cab4e61 100644
>> --- a/include/uapi/linux/btf.h
>> +++ b/include/uapi/linux/btf.h
>> @@ -33,20 +33,22 @@ struct btf_header {
>> __u32 layout_len; /* length of layout section */
>> };
>>
>> -/* Max # of type identifier */
>> -#define BTF_MAX_TYPE 0x000fffff
>> -/* Max offset into the string section */
>> -#define BTF_MAX_NAME_OFFSET 0x00ffffff
>> -/* Max # of struct/union/enum members or func args */
>> -#define BTF_MAX_VLEN 0xffff
>> +enum btf_max {
>> + /* Max possible kind */
>> + BTF_MAX_KIND = 0x0000007f,
>> + /* Max # of type identifier */
>> + BTF_MAX_TYPE = 0x000fffff,
>> + /* Max offset into the string section */
>> + BTF_MAX_NAME_OFFSET = 0x00ffffff,
>> + /* Max # of struct/union/enum members or func args */
>> + BTF_MAX_VLEN = 0x00ffffff,
>> +};
>
> Could replacing these #define macros with an enum break existing userspace
> applications?
>
> Programs using #ifdef BTF_MAX_VLEN or evaluating #if BTF_MAX_VLEN == ...
> for conditional compilation will fail to build without the preprocessor
> macros.
>
> Would it be better to redefine the macros alongside the enums
> (e.g., #define BTF_MAX_VLEN BTF_MAX_VLEN) to maintain UAPI backward
> compatibility while still exposing the constants to BTF?
>

Looks like this is done on purpose and we don't expect anyone actually
use #ifdef BTF_MAX_VLEN, so it's an acceptable change.

> [ ... ]
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index a62d785812076..1663970fc1bf6 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -289,7 +288,7 @@ enum verifier_phase {
>> struct resolve_vertex {
>> const struct btf_type *t;
>> u32 type_id;
>> - u16 next_member;
>> + u32 next_member;
>> };
>
> Does the env_stack_set_next_member() helper also need its next_member
> argument updated to u32?
>
> Looking at env_stack_set_next_member() in kernel/bpf/btf.c:
>
> static void env_stack_set_next_member(struct btf_verifier_env *env,
> u16 next_member)
> {
> env->stack[env->top_stack - 1].next_member = next_member;
> }
>
> Since the argument is still u16, won't this silently truncate the i + 1
> index for any struct or datasec member beyond 65,535?
>
> If this happens, when the verifier resumes resolution of the struct, could
> it restart from the truncated index and redundantly iterate over
> already-resolved members? With a very large number of members, could this
> cause excessive CPU usage or soft lockups?
>