Re: [PATCH v2 bpf-next 2/8] libbpf: Adjust btf_vlen() to return a __u32

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] btf__add_field() manually increments vlen without checking for BTF_MAX_VLEN overflow, leading to silent BTF type corruption.
--

commit bc2a5650478dca79064a34b0022bfd5fa6e2da77
Author: Alan Maguire <alan.maguire@oracle.com>

    libbpf: Adjust btf_vlen() to return a __u32
    
    Now that vlen is 24 bits, btf_vlen() must return a __u32.
    Adjust use cases in libbpf accordingly.  Also add error
    handling to avoid vlen overflow in btf_type_inc_vlen().

> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
[ ... ]
> @@ -2121,9 +2121,12 @@ static void *btf_add_type_mem(struct btf *btf, size_t add_sz)
>  			      btf->hdr.type_len, UINT_MAX, add_sz);
>  }
>  
> -static void btf_type_inc_vlen(struct btf_type *t)
> +static int btf_type_inc_vlen(struct btf_type *t)
>  {
> +	if (btf_vlen(t) == BTF_MAX_VLEN)
> +		return -ENOSPC;
>  	t->info = btf_type_info(btf_kind(t), btf_vlen(t) + 1, btf_kflag(t));
> +	return 0;
>  }

Does btf__add_field() also need to check for BTF_MAX_VLEN overflow?

It looks like btf__add_field() manually increments the length without using
btf_type_inc_vlen() to preserve the kflag:

	t = btf_last_type(btf);
	/* update parent type's vlen and kflag */
	t->info = btf_type_info(btf_kind(t), btf_vlen(t) + 1, is_bitfield || btf_kflag(t));

If a struct or union exceeds the maximum number of members, could this
increment overflow into the kind bits and corrupt the BTF type boundaries?

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