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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox