Re: [PATCH bpf-next v2 16/20] libbpf: Carry the exception cleanup table through the light skeleton

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] libbpf: integer overflow in cleanup_info_tot_sz leads to heap OOB read/write
--

commit b9300a1f6022da2aa8b343e05882b46e9f329c64
Author: Yonghong Song <yonghong.song@linux.dev>

libbpf: Carry the exception cleanup table through the light skeleton

This patch modifies the light skeleton generation to carry the exception
cleanup table (cleanup_info), similar to func_info and line_info. It updates
bpf_gen__prog_load() to allocate space for the records, set up union bpf_attr,
and perform endianness swapping for cross-compiled cases.

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index af3a04f161ac1..2345fbdd46f56 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
[ ... ]
> @@ -998,6 +1000,9 @@ static void info_blob_bswap(struct bpf_gen *gen, int func_info, int line_info,
>  
>  	for (i = 0; i < gen->core_relo_cnt; i++)
>  		bpf_core_relo_bswap(cr++);
> +
> +	for (i = 0; i < load_attr->cleanup_info_cnt; i++)
> +		bpf_cleanup_info_bswap(ci++);

[Severity: High]
Could this loop result in an out-of-bounds heap read and write?

If an attacker crafts a BPF ELF object with an extremely large .bpf_cleanup
section, load_attr->cleanup_info_cnt can be very large. If the allocation
size calculated in bpf_gen__prog_load() overflowed, this loop will process
hundreds of millions of elements in an undersized buffer.

This could cause memory corruption when cross-compiling (gen->swapped_endian
is true).

>  }
>  
>  void bpf_gen__prog_load(struct bpf_gen *gen,
> @@ -1011,8 +1016,11 @@ void bpf_gen__prog_load(struct bpf_gen *gen,
>  			       load_attr->line_info_rec_size;
>  	int core_relo_tot_sz = gen->core_relo_cnt *
>  			       sizeof(struct bpf_core_relo);
> +	int cleanup_info_tot_sz = load_attr->cleanup_info_cnt *
> +				  load_attr->cleanup_info_rec_size;

[Severity: High]
Does this unbounded 32-bit integer multiplication risk an overflow?

If load_attr->cleanup_info_cnt is excessively large, multiplying it by
cleanup_info_rec_size could wrap around modulo 2^32 to a small positive
integer. This would result in add_data() allocating an undersized heap
buffer for the cleanup info blob.

Combined with the loop in info_blob_bswap(), this could lead to crashes
or potentially arbitrary code execution when processing untrusted files
using the light skeleton generator.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918044156.3283973-1-yonghong.song@linux.dev?part=16