Re: [PATCH bpf-next v3 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] bpf: Integer overflow in cleanup_info_tot_sz leads to heap buffer overflow
--

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

libbpf: Carry the exception cleanup table through the light skeleton

This commit updates the light skeleton generator to emit BPF_PROG_LOAD
instructions that include the exception cleanup table. It stores the cleanup
records in the loader's bytes blob, calculates the needed buffer size, and
byte-swaps the records for cross-endian builds.

> 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]
Does this loop write beyond the allocated buffer if cleanup_info_tot_sz
overflowed during its calculation?

If an untrusted user provides a malicious BPF ELF object with a very large
.bpf_cleanup section, load_attr->cleanup_info_cnt can be extremely large.
The loop uses this un-wrapped count to byte-swap entries, writing past the
end of the buffer if the allocation size was wrapped.

>  }
>  
>  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]
Can this multiplication overflow a 32-bit integer?

If load_attr->cleanup_info_cnt is a huge value (e.g., 0x15555556),
multiplying it by cleanup_info_rec_size (12) will wrap around a 32-bit
integer. 

This would result in a small wrapped value being assigned to
cleanup_info_tot_sz (e.g., 0x15555556 * 12 = 4294967304, wrapping to 8).
The resulting undersized allocation passed to add_data() would then lead
to the out-of-bounds write in info_blob_bswap().

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