Re: [PATCH v10 bpf-next 02/10] libbpf: Support layout section handling in BTF

On Fri, Feb 27, 2026 at 2:52 AM <[email protected]> wrote:
>
> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index 83fe79ffcb8f..7b58724a90a2 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
>
> [ ... ]
>
> >  static int btf_parse_hdr(struct btf *btf)
> >  {
> > -     struct btf_header *hdr = btf->hdr;
> > +     struct btf_header *hdr = btf->raw_data;
> > +     __u32 hdr_len = hdr->hdr_len;
> >       __u32 meta_left;
> >
> > -     if (btf->raw_size < sizeof(struct btf_header)) {
> > +     if (btf->raw_size < offsetofend(struct btf_header, str_len)) {
> >               pr_debug("BTF header not found\n");
> >               return -EINVAL;
> >       }
>
> Could the read of hdr->hdr_len at offset 4 above be an out-of-bounds
> access when raw_size is less than 8?
>
> The previous code set hdr as a pointer without dereferencing it, then
> checked raw_size before accessing any header fields.  The new code
> reads hdr->hdr_len before the raw_size check.
>
> btf_new() calls btf_parse_hdr() with whatever size the caller provided
> via btf__new() or btf_parse_elf(), so small or corrupt input could
> reach here.  On the mmap path the data could sit at a page boundary
> where offset 4 would fault.
>
> Moving the initialization of hdr_len to after the size check would
> restore the pre-patch safety:
>
>     struct btf_header *hdr = btf->raw_data;
>     __u32 hdr_len;
>     __u32 meta_left;
>
>     if (btf->raw_size < offsetofend(struct btf_header, str_len)) {
>         ...
>     }
>
>     hdr_len = hdr->hdr_len;

bot is correct.
Let's avoid potential oob read.