Re: [PATCH bpf-next v8 4/9] libbpf: Add support for global percpu data

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Integer truncation in `bpf_object__init_internal_map` leads to buffer overflow when parsing ELF sections larger than 4GB.
--

commit 03705a88bed3644f27861637702d0bad3472613b
Author: Leon Hwang <leon.hwang@linux.dev>

libbpf: Add support for global percpu data

This commit adds support for global percpu data in libbpf by adding a new
".percpu" section. It enables efficient handling of percpu global variables
in BPF programs by using BPF_F_ALL_CPUS during map updates. The mmaped data
is marked as read-only after map population for syscalls.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 7162146280a80..6e18a1628e139 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -1983,7 +1989,7 @@ bpf_object__init_internal_map(struct bpf_object *obj, enum libbpf_map_type type,
>  	}
>  
>  	def = &map->def;
> -	def->type = BPF_MAP_TYPE_ARRAY;
> +	def->type = is_percpu ? BPF_MAP_TYPE_PERCPU_ARRAY : BPF_MAP_TYPE_ARRAY;
>  	def->key_size = sizeof(int);
>  	def->value_size = data_sz;

[Severity: High]
This is a pre-existing issue, but could this integer truncation lead to a
buffer overflow?

If a user supplies a crafted ELF file with a section (like .data, .rodata,
or .percpu) larger than 4GB, the 64-bit data_sz is implicitly truncated when
assigned to the 32-bit def->value_size.

This results in a smaller mmap allocation based on the truncated value. Later
in bpf_object__init_internal_map(), memcpy uses the original 64-bit data_sz:

	if (data)
		memcpy(map->mmaped, data, data_sz);

Can this overflow the allocated buffer when parsing unverified BPF objects?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629152406.52582-1-leon.hwang@linux.dev?part=4