BPF List
 help / color / mirror / Atom feed
From: Nicholas Dudar <main.kalliope@gmail.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	eddyz87@gmail.com, memxor@gmail.com
Subject: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max
Date: Thu,  9 Jul 2026 11:58:36 -0400	[thread overview]
Message-ID: <20260709155837.1879230-2-main.kalliope@gmail.com> (raw)
In-Reply-To: <20260709155837.1879230-1-main.kalliope@gmail.com>

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
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.

Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the
point meta->r0_size is set, 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
---
 kernel/bpf/verifier.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 233472a871be..c7fabe50e487 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -12097,6 +12097,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 				}
 
 				meta->r0_size = reg->var_off.value;
+				if (meta->r0_size > U32_MAX) {
+					verbose(env, "%s rdonly/rdwr_buf_size exceeds u32 max\n",
+						reg_arg_name(env, argno));
+					return -EINVAL;
+				}
 				if (regno >= 0)
 					ret = mark_chain_precision(env, regno);
 				else
-- 
2.34.1


  reply	other threads:[~2026-07-09 16:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 15:58 [PATCH bpf-next v2 0/2] bpf: bound rdonly/rdwr_buf_size kfunc return size Nicholas Dudar
2026-07-09 15:58 ` Nicholas Dudar [this message]
2026-07-09 16:15   ` [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max sashiko-bot
2026-07-09 20:01     ` Amery Hung
2026-07-09 20:29       ` Kumar Kartikeya Dwivedi
2026-07-09 21:50         ` Amery Hung
2026-07-09 20:02   ` Eduard Zingerman
2026-07-09 15:58 ` [PATCH bpf-next v2 2/2] selftests/bpf: add test for oversized rdonly/rdwr_buf_size kfunc argument Nicholas Dudar
2026-07-09 20:02   ` Eduard Zingerman
2026-07-09 20:30 ` [PATCH bpf-next v2 0/2] bpf: bound rdonly/rdwr_buf_size kfunc return size patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260709155837.1879230-2-main.kalliope@gmail.com \
    --to=main.kalliope@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=memxor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox