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

[sashiko-bot@kernel.org]

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?

[ ... ]

> 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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260414195019.684531-1-alan.maguire@oracle.com?part=1