> 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.
Reference:
https://lore.kernel.org/bpf/[email protected]/
From: [email protected]
Date: Wed, 03 Jun 2026 15:14:05 +0000
> if (err)
> return err;
> info_len = min_t(u32, sizeof(info), info_len);
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26960942650
