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

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

On 9/19/26 11:01 PM, sashiko-bot@kernel.org wrote:
> 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().

Overflow is indeed possible. Will fix it, e.g. with cleanup_info_tot_sz as __u64
and later check against INT32_MAX.