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

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

On 2/7/26 03:31, Andrii Nakryiko wrote:
> On Mon, Jun 29, 2026 at 10:55 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> 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.
> 
> No, don't. All this hardening of libbpf is nonsensical. libbpf is not
> meant to protect against corrupted ELF. If you don't trust the source
> of ELF, you should definitely not attempt to open BPF object and load
> it into kernel to run with root-like capabilities.
> 
Got it.

I didn't post the separate patch.

Thanks,
Leon