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. pw-bot: cr
