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

[Guangshuo Li]

Hi Varun,

Thanks for the review.

On Mon, 6 Jul 2026 at 06:39, Varun R Mallya <varunrmallya@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx>
> > ---
> >  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
> >

You are right, checking t->size is too strict for
packed bitfields where the backing integer type can be larger than the
actual object bytes covering the field.

I'll send a v2 that keeps the nr_bytes bounds check and instead changes
the value-building loops to consume only the checked byte range.

Thanks,
Guangshuo