Re: [PATCH v6 bpf-next 03/10] libbpf: use kind layout to compute an unknown kind size

[Alan Maguire <alan.maguire@oracle.com>]

On 10/12/2025 20:55, bot+bpf-ci@kernel.org wrote:
>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>> index 737adc560818..4eb0704a0309 100644
>> --- a/tools/lib/bpf/btf.c
>> +++ b/tools/lib/bpf/btf.c
> 
> [ ... ]
> 
>> +/* for unknown kinds, consult kind layout. */
>> +static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t)
>> +{
>> +	int size = sizeof(struct btf_type);
>> +	struct btf_kind_layout *k = NULL;
>> +	__u16 vlen = btf_vlen(t);
>> +	__u8 kind = btf_kind(t);
>> +
>> +	if (btf->kind_layout)
>> +		k = &((struct btf_kind_layout *)btf->kind_layout)[kind];
>> +
>> +	if (!k || (void *)k > ((void *)btf->kind_layout + btf->hdr->kind_layout_len)) {
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Can the bounds check be moved before the array access?  Currently the code
> indexes into kind_layout[kind] before validating whether 'kind' is within
> bounds.  While computing an out-of-bounds pointer may not cause immediate
> issues, the bounds check itself appears incorrect.
> 
> The check uses '>' which allows access when k points exactly to the end of
> the array. For example, if kind_layout_len is 40 bytes (20 kinds * 2 bytes
> each) and kind is 20, then k would point to offset 40, and the check
> '(ptr at 40) > (ptr at 40)' evaluates to false, allowing the subsequent
> read of k->info_sz at an out-of-bounds location.
> 
> Should this be: 'if (!btf->kind_layout || kind >= (btf->hdr->kind_layout_len
> / sizeof(*k)))'?  This would validate the index before the array access and
> ensure the full structure can be read safely.
> 

Yep, good suggestion. Will fix.

>> +		pr_debug("Unsupported BTF_KIND: %u\n", btf_kind(t));
>> +		return -EINVAL;
>> +	}
>> +
>> +	size += k->info_sz;
>> +	size += vlen * k->elem_sz;
>> +
>> +	return size;
>> +}
> 
> [ ... ]
> 
> 
> ---
> 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/20112692486