On 5/6/26 00:39, Alexei Starovoitov wrote: > On Thu, Jun 4, 2026 at 8:45 AM <[email protected]> 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
