> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index 1007fb7c87e9..0c86a70d31c1 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);
A concern raised during the v1 review on the list does not appear to have been resolved in the code, so it seems worth raising again here. With len now equal to 228 instead of sizeof(info) == 232, a caller that passes info_len == 232 will have actual_size (232) greater than expected_size (228), so bpf_check_uarg_tail_zero() will actively check the 4 padding bytes and return -E2BIG when they contain garbage. Could this reject callers that work today? An existing binary that allocates struct bpf_prog_info on the stack and passes info_len == 232 without zeroing the trailing padding would have hit the fast path (actual_size <= expected_size) before this change and returned 0. There was also a question about whether this actually prevents the future-field scenario described in the commit message. If a later kernel adds a new 4-byte field, the struct size stays 232 and that kernel's expected_size becomes 232, so an old binary passing info_len == 232 hits the fast path again and the uninitialized padding is consumed as the new field. For reference, the original discussion is here: https://lore.kernel.org/bpf/[email protected]/ > 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
