Re: [PATCH] libbpf: Check full backing type size for bitfield dump

[Varun R Mallya <varunrmallya@gmail.com>]

On Sun, Jul 05, 2026 at 11:26:03AM +0800, Guangshuo Li wrote:
> btf_dump_get_bitfield_value() builds a bitfield value by reading bytes
> from the backing integer type. The bounds check added for short data
> buffers uses the number of bytes covered by the bitfield itself, but the
> read loop consumes the full backing type width.
> 
> For narrow bitfields this can leave part of the backing type unchecked.
> For example, a one-bit field backed by a four-byte integer only requires
> one byte according to the bitfield span calculation, while the value
> construction still reads four bytes.
> 
> Check the backing type size instead, so the bounds check matches the
> actual read range.
> 
> Fixes: 5714ca8cba5e ("libbpf: Fix OOB read in btf_dump_get_bitfield_value")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
>  tools/lib/bpf/btf_dump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
> index cc1ba65bb6c5..a49790e356a8 100644
> --- a/tools/lib/bpf/btf_dump.c
> +++ b/tools/lib/bpf/btf_dump.c
> @@ -1771,7 +1771,7 @@ static int btf_dump_get_bitfield_value(struct btf_dump *d,
>  	nr_bytes = (start_bit + bit_sz + 7) / 8;

nr_bytes and the line before it are made obsolete due to your change and
become an unused variable, so that would need cleanup, as sashiko
correctly pointed out.

>  	/* Bound check */
> -	if (data + nr_bytes > d->typed_dump->data_end)
> +	if (data + t->size > d->typed_dump->data_end)

The fix does not seem right to me. This will reject
something like:

  struct packed_int8 {
        int a:8;
  } __attribute__((packed));

with BTF output like:

  STRUCT 'packed_int8' size=1
    'a' type_id=2 bits_offset=0 bitfield_size=8
  INT 'int' size=4

As you can see, this valid object has a size of 1 but BTF type has size
4.
nr_bytes (the old one), would get calculated as 1, and t->size would
show up as 4. This will unncessarily reject valid data.

I do understand the concern with the loops below using t->size but the
check happening on a value calculated separately, and this can actually
trigger an OOB. You could maybe try fixing the loops instead by handling
packed bitfields (like the case I gave) specially, but making the check
more strict is something I don't think is helpful.

>  		return -E2BIG;
>  
>  	/* Maximum supported bitfield size is 64 bits */
> -- 
> 2.43.0
>