Re: [PATCH bpf-next 2/3] bpf: Check tail zero of bpf_prog_info

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] UAPI regression and fundamentally flawed forward-compatibility logic due to strict zero-checks on previously ignored struct padding.
--

commit 7758939eea6a099c4db0364bf334e0034c2864fc
Author: Leon Hwang <leon.hwang@linux.dev>

bpf: Check tail zero of bpf_prog_info

This commit changes the size passed to bpf_check_uarg_tail_zero() to exclude
the trailing padding of struct bpf_prog_info. The goal is to prevent older
userspace programs from passing uninitialized stack garbage into a future
4-byte field.

Link: https://lore.kernel.org/bpf/20260513224823.6494FC19425@smtp.kernel.org/

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 1007fb7c87e91..0c86a70d31c17 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -5115,10 +5115,11 @@ static int bpf_prog_get_info_by_fd(struct file *file,
>  	u32 info_len = attr->info.info_len;
>  	struct bpf_prog_kstats stats;
>  	char __user *uinsns;
> -	u32 ulen;
> +	u32 ulen, len;
>  	int err;
>  
> -	err = bpf_check_uarg_tail_zero(USER_BPFPTR(uinfo), sizeof(info), info_len);
> +	len = offsetofend(struct bpf_prog_info, attach_btf_id);
> +	err = bpf_check_uarg_tail_zero(USER_BPFPTR(uinfo), len, info_len);

[Severity: Critical]
Does this change break the ABI for existing deployed binaries?

Previously, expected_size was 232 (sizeof(info)). If an existing binary
passes info_len = 232 with uninitialized stack garbage in the 4-byte
padding, bpf_check_uarg_tail_zero() would see actual_size <= expected_size
(232 <= 232) and immediately return 0.

By reducing expected_size to 228, actual_size > expected_size (232 > 228),
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 232, and
the new kernel's expected_size will be 232. At that point, those old buggy
binaries passing info_len = 232 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.

>  	if (err)
>  		return err;
>  	info_len = min_t(u32, sizeof(info), info_len);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603144518.67065-1-leon.hwang@linux.dev?part=2