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

[Yonghong Song <yonghong.song@linux.dev>]

On 9/17/26 10:02 PM, sashiko-bot@kernel.org wrote:
> 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).

It is user's problem if they intentionally want to have of lots and lots of
.bpf_cleanup section.

>
>>   }
>>   
>>   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.

We should be okay. Similar to line_info, core_relo, etc., all of them
(including cleanup_info) will have a guard in add_data which ensures
the total size must be smaller than INT32_MAX.

>