[PATCH 5.10-6.18] libbpf: fix cross-endian build with newer libbpf

[PATCH 5.10-6.18] libbpf: fix cross-endian build with newer libbpf

[Dominique Martinet]

commit 087f3964f4b3 ("libbpf: Support layout section handling in BTF")
added extra data to the BTF header.

This extra data is ignored in the native case, but when building with
different endianness the bswap code in old libbpf would check for strict
size equality, leading to build failures such as this when BTF data is
generated with a newer version of libbpf (through pahole)
    BTFIDS  vmlinux.unstripped
  libbpf: Can't load BTF with non-native endianness due to unsupported header length 32
  FAILED: load BTF from vmlinux.unstripped: Operation not supported
  make[2]: *** [../scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 255

Newer libbpf versions also properly ignore trailing data in the bswap
case, but the patch is too intrusive to backport, just fix the header
length comparison.

Link: https://github.com/NixOS/nixpkgs/pull/570639
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
---
Hey,

we've got a cross build failure report for ppc64 in nixpkgs (link in
commit message), that turned out as described above.
(build broke for all kernels before 7.1)

In this case I believe it's easier to just fix the check than backport
the full layout section handling support, is that ok?
I've confirmed the build succeeds with this, I assume the reporter will
eventually also boot check but from my understanding of the code this
should be fine.

Feel free to throw this away if there's a better way, just let me know
if I can help.

Thanks

 tools/lib/bpf/btf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index 9f141395c074..ae344cf58e85 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -236,7 +236,7 @@ static int btf_parse_hdr(struct btf *btf)
 
 	if (hdr->magic == bswap_16(BTF_MAGIC)) {
 		btf->swapped_endian = true;
-		if (bswap_32(hdr->hdr_len) != sizeof(struct btf_header)) {
+		if (bswap_32(hdr->hdr_len) < sizeof(struct btf_header)) {
 			pr_warn("Can't load BTF with non-native endianness due to unsupported header length %u\n",
 				bswap_32(hdr->hdr_len));
 			return -ENOTSUP;
-- 
2.56.1

Re: [PATCH 5.10-6.18] libbpf: fix cross-endian build with newer libbpf

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Low] libbpf: missing Fixes trailer for btf_parse_hdr() endianness
  check
- [Low] libbpf: out-of-bounds access in btf_parse_hdr() when hdr_len >
  sizeof(*hdr)
--

commit c3e5e38661056ceb32071ab50ba595824eefbdbf
Author: Dominique Martinet <asmadeus@codewreck.org>

> libbpf: fix cross-endian build with newer libbpf
>
> commit 087f3964f4b3 ("libbpf: Support layout section handling in BTF")
> added extra data to the BTF header.
>
> This extra data is ignored in the native case, but when building with
> different endianness the bswap code in old libbpf would check for strict
> size equality, leading to build failures such as this when BTF data is
> generated with a newer version of libbpf (through pahole)
>     BTFIDS  vmlinux.unstripped
>   libbpf: Can't load BTF with non-native endianness due to unsupported header length 32
>   FAILED: load BTF from vmlinux.unstripped: Operation not supported
>   make[2]: *** [../scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 255
>
> Newer libbpf versions also properly ignore trailing data in the bswap
> case, but the patch is too intrusive to backport, just fix the header
> length comparison.
>
> Link: https://github.com/NixOS/nixpkgs/pull/570639
> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>

[Severity: Low]
Should this include a Fixes tag for the commit that introduced the strict
swapped-endian header size check:

  Fixes: 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")

> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index 231b07203e3d2..8f3f942eda704 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -198,7 +198,7 @@ static int btf_parse_hdr(struct btf *btf)
>  
>  	if (hdr->magic == bswap_16(BTF_MAGIC)) {
>  		btf->swapped_endian = true;
> -		if (bswap_32(hdr->hdr_len) != sizeof(struct btf_header)) {
> +		if (bswap_32(hdr->hdr_len) < sizeof(struct btf_header)) {
>  			pr_warn("Can't load BTF with non-native endianness due to unsupported header length %u\n",
>  				bswap_32(hdr->hdr_len));
>  			return -ENOTSUP;

[Severity: Low]
Can relaxing this check cause out-of-bounds reads and writes on
btf->raw_data when parsing a malformed cross-endian BTF buffer with
hdr->hdr_len > sizeof(*hdr)?

Previously, requiring hdr->hdr_len == sizeof(struct btf_header) together
with btf->raw_size >= sizeof(struct btf_header) guaranteed hdr->hdr_len
fit within btf->raw_size.  btf_parse_hdr() still computes meta_left from
sizeof(*hdr) instead of hdr->hdr_len:

tools/lib/bpf/btf.c:btf_parse_hdr() {
	...
	meta_left = btf->raw_size - sizeof(*hdr);
	...
}

However, btf__new() offsets the section pointers by btf->hdr->hdr_len:

tools/lib/bpf/btf.c:btf__new() {
	...
	btf->strs_data = btf->raw_data + btf->hdr->hdr_len + btf->hdr->str_off;
	btf->types_data = btf->raw_data + btf->hdr->hdr_len + btf->hdr->type_off;
	...
}

If hdr->hdr_len exceeds sizeof(*hdr) (or exceeds btf->raw_size),
btf->strs_data and btf->types_data can point past btf->raw_data +
btf->raw_size, causing btf_parse_str_sec() to read out of bounds and
btf_parse_type_sec() to byte-swap memory in place past the end of the heap
buffer.  Checking that btf->raw_size >= hdr->hdr_len and subtracting
hdr->hdr_len when computing meta_left would avoid this.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115200505.1494710-2-asmadeus@codewreck.org?part=1

Re: [PATCH 5.10-6.18] libbpf: fix cross-endian build with newer libbpf

[Dominique Martinet]

sashiko-bot@kernel.org wrote on Sun, Nov 15, 2026 at 08:23:16PM +0000:
> > Link: https://github.com/NixOS/nixpkgs/pull/570639
> > Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
> 
> [Severity: Low]
> Should this include a Fixes tag for the commit that introduced the strict
> swapped-endian header size check:
> 
>   Fixes: 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")

Err, yeah, I guess that bug couldn't happen before support for
endianness was added, but it didn't work before either so meh :)
Feel free to add when applying if you think it helps.

> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index 231b07203e3d2..8f3f942eda704 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
> > @@ -198,7 +198,7 @@ static int btf_parse_hdr(struct btf *btf)
> >  
> >  	if (hdr->magic == bswap_16(BTF_MAGIC)) {
> >  		btf->swapped_endian = true;
> > -		if (bswap_32(hdr->hdr_len) != sizeof(struct btf_header)) {
> > +		if (bswap_32(hdr->hdr_len) < sizeof(struct btf_header)) {
> >  			pr_warn("Can't load BTF with non-native endianness due to unsupported header length %u\n",
> >  				bswap_32(hdr->hdr_len));
> >  			return -ENOTSUP;
> 
> [Severity: Low]
> Can relaxing this check cause out-of-bounds reads and writes on
> btf->raw_data when parsing a malformed cross-endian BTF buffer with
> hdr->hdr_len > sizeof(*hdr)?
> 
> Previously, requiring hdr->hdr_len == sizeof(struct btf_header) together
> with btf->raw_size >= sizeof(struct btf_header) guaranteed hdr->hdr_len
> fit within btf->raw_size.  btf_parse_hdr() still computes meta_left from
> sizeof(*hdr) instead of hdr->hdr_len:
> 
> tools/lib/bpf/btf.c:btf_parse_hdr() {
> 	...
> 	meta_left = btf->raw_size - sizeof(*hdr);
> Sashiko AI review · https://sashiko.dev/#/patchset/20261115200505.1494710-2-asmadeus@codewreck.org?part=1

sashiko apparently picked the v5.10 tag, but this bad sizeof was fixed
in commit c825f5fee19c ("libbpf: Fix BTF header parsing checks") and
isn't a problem as far as I can tell (that commit was backported to all
stable kernels, and header is properly used, after endianness swap)

Thanks,
-- 
Dominique Martinet | Asmadeus