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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.