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

[Leon Hwang <leon.hwang@linux.dev>]

On 29/6/26 23:40, sashiko-bot@kernel.org wrote:
[...]
>> @@ -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?
> 

Sounds reasonable.

The data_sz value comes from the ELF file and therefore cannot be
trusted, as the section size can be malformed.

For example, readelf -a shows the following for a normal ELF:

  [ 3] .data             PROGBITS         0000000000000000  00000040
       0000000000000004  0000000000000000  WA       0     0     4

The section size can be modified to:

  [ 3] .data             PROGBITS         0000000000000000  00000040
       0000000100000001  0000000000000000  WA       0     0     4

In this case, data_sz would be truncated to 1.

However, in practice, there won't be larger than 4GB section in bpf ELF
file. And, it is meaningless to hack libbpf to corrupt user space memory.

Of course, will post a separate patch for further discussion.

Thanks,
Leon