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

On 4/14/26 10:11 PM, [email protected] 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 <[email protected]>
> 
> 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?
>