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

[sashiko-bot@kernel.org]

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