Re: [PATCH bpf-next v2 1/3] bpf: Check tail zero of bpf_map_info

[Leon Hwang]

On 5/6/26 00:39, Alexei Starovoitov wrote:
> On Thu, Jun 4, 2026 at 8:45 AM <bot+bpf-ci@xxxxxxxxxx> wrote:
>>
>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>> index 625a4366fe6d..1007fb7c87e9 100644
>>> --- a/kernel/bpf/syscall.c
>>> +++ b/kernel/bpf/syscall.c
>>> @@ -5400,10 +5400,11 @@ static int bpf_map_get_info_by_fd(struct file *file,
>>>  {
>>>       struct bpf_map_info __user *uinfo = u64_to_user_ptr(attr->info.info);
>>>       struct bpf_map_info info;
>>> -     u32 info_len = attr->info.info_len;
>>> +     u32 info_len = attr->info.info_len, len;
>>>       int err;
>>>
>>> -     err = bpf_check_uarg_tail_zero(USER_BPFPTR(uinfo), sizeof(info), info_len);
>>> +     len = offsetofend(struct bpf_map_info, hash_size);
>>> +     err = bpf_check_uarg_tail_zero(USER_BPFPTR(uinfo), len, info_len);
>>
>> Does this change break the ABI for existing deployed binaries? Previously,
>> expected_size was 104 (sizeof(info)). If an existing binary passes info_len
>> = 104 with uninitialized stack garbage in the 4-byte padding,
>> bpf_check_uarg_tail_zero() would see actual_size <= expected_size (104 <=
>> 104) and immediately return 0.
>>
>> By reducing expected_size to 100, actual_size > expected_size (104 > 100),
>> so bpf_check_uarg_tail_zero() will actively check the 4 padding bytes and
>> return -E2BIG if they contain garbage. This rejects previously working
>> applications.
>>
>> Additionally, does this actually protect against the stated future issue?
>> If a future kernel adds a new 4-byte field, the struct size stays 104, and
>> the new kernel's expected_size will be 104. At that point, those old buggy
>> binaries passing info_len = 104 will once again hit the fast path
>> (actual_size <= expected_size), skipping the check and allowing the
>> uninitialized padding to be consumed as the new field.
> 
> bot's concerns are valid.
> Let's add __u32 :32 to bpf_map_info at the same time.
> 
Will add it.

Thanks,
Leon