Re: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2026-07-09 at 11:58 -0400, Nicholas Dudar wrote:

Hi Nicholas,

Thank you for the patch. This patch-set lgtm, but please try to make
commit messages more concise in future submissions. E.g. for this one
Claude added a completely unnecessary amount of details.

> check_kfunc_args() detects a kfunc argument named rdonly_buf_size or
> rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64,
> and does not bound it. check_kfunc_call() later copies that value into
> the returned register's mem_size field:
> 
>   meta->r0_size = reg->var_off.value;
>   ...
>   regs[BPF_REG_0].mem_size = meta.r0_size;
> 
> regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are
> set, such as 2^64 - 192, truncates to 0xffffff40 instead of causing a

Nit: reference to a specific constant is misleading here.

> load-time rejection, so the verifier records a PTR_TO_MEM register
> with an approximately 4 GiB mem_size for whatever allocation the kfunc
> returned. A later access check against that register uses the
> truncated, wrong bound.
> 
> check_kfunc_args() is the site that stores this value for kfuncs that
> declare an rdonly_buf_size or rdwr_buf_size argument.
> hid_bpf_get_data() (drivers/hid/bpf/hid_bpf_dispatch.c) takes an
> rdwr_buf_size argument this way and is reachable from a
> BPF_PROG_TYPE_STRUCT_OPS HID-BPF program; io_uring/bpf-ops.c:26,47
> declares one as well. The fix belongs at check_kfunc_args(), the
> truncation site. The kfunc's runtime check still guards its allocation
> bound, but it should not have to defend against a size the verifier
> already mis-recorded.
> 
> bpf_obj_new refuses a local type ID that does not fit u32
> (check_special_kfunc()). check_kfunc_args() does not bound the
> rdonly_buf_size/rdwr_buf_size value that feeds mem_size.

Nit: the above two paragraphs are not necessary.

> Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the
> point meta->r0_size is set,

Nit: the below paragraph is not necessary.

> ahead of mark_chain_precision() and the
> later PTR_TO_MEM assignment. The preceding tnum_is_const() check
> already requires the argument to be a known constant, so
> reg->var_off.value is the exact size and rejecting it is sound. U32_MAX
> is the minimal bound that keeps the recorded mem_size within the u32
> field; a tighter semantic maximum is out of scope.
> 
> Fixes: eb1f7f71c126 ("bpf/verifier: allow kfunc to return an allocated mem")
> Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
> Assisted-by: Claude:claude-opus-4-8
> ---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]