Re: [PATCH bpf-next v2 1/2] bpf: reject BPF_PROG_QUERY with short uattr size

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The patch unconditionally rejects BPF_PROG_QUERY requests with a smaller attribute size, breaking backward compatibility for older userspace applications.
- [Low] Returning -EFAULT for a structure size mismatch is semantically incorrect.
--

commit 205b70f382d21dfafc18f8275384ff0f06e59f6e
Author: Yuyang Huang <yuyanghuang@google.com>

bpf: reject BPF_PROG_QUERY with short uattr size

This commit modifies bpf_prog_query() to return an error if the user-provided
attribute size is smaller than the offset of the query.revision field. This
aims to prevent an out-of-bounds write to userspace.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 9e91fb2fb492c..4dbf53e81a38c 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -4719,8 +4719,10 @@ static int bpf_prog_detach(const union bpf_attr *attr)
>  #define BPF_PROG_QUERY_LAST_FIELD query.revision
>  
>  static int bpf_prog_query(const union bpf_attr *attr,
> -			  union bpf_attr __user *uattr)
> +			  union bpf_attr __user *uattr, u32 uattr_size)
>  {
> +	if (uattr_size < offsetofend(union bpf_attr, query.revision))

[Severity: Critical]
Does this unconditionally reject older userspace applications that pass a
smaller uattr_size? The BPF syscall generally maintains backward
compatibility by allowing older binaries to pass smaller structures.

By rejecting the call entirely at the top-level dispatcher, wouldn't this
break ABI for all attachment types (like BPF_FLOW_DISSECTOR), even if those
specific handlers never attempt to write to query.revision?

Could we instead pass uattr_size down to the lower-level query handlers and
conditionally skip writing the revision field to user space when the provided
buffer size is insufficient?

> +		return -EFAULT;

[Severity: Low]
Is -EFAULT the correct error code for a structure size mismatch?

Standard practice usually returns -EINVAL (or -E2BIG) for mismatched or
inadequate sizes. -EFAULT typically indicates an invalid memory address
during a copy operation, which might mislead userspace developers trying to
debug their applications.

>  	if (!bpf_net_capable())
>  		return -EPERM;
>  	if (CHECK_ATTR(BPF_PROG_QUERY))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260531004748.3567875-1-yuyanghuang@google.com?part=1