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

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

> 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/20260603151405.6DB111F00893@smtp.kernel.org/
From: sashiko-bot@kernel.org
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