From: Yonghong Song <yonghong.song@linux.dev>
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
kernel-team@fb.com
Subject: [PATCH bpf-next v3 08/13] bpf: Reject register-pair returns when the subprog BTF is unreliable
Date: Sat, 8 Aug 2026 12:04:03 -0700 [thread overview]
Message-ID: <20260808190403.1900396-1-yonghong.song@linux.dev> (raw)
In-Reply-To: <20260808190322.1896580-1-yonghong.song@linux.dev>
The R0:R2 return convention is derived from the BTF function prototype:
bpf_compute_subprog_ret_regs() inspects the return type of every
subprogram and records whether its value comes back in a register pair.
btf_check_subprog_call() can decide, at a call site, that this BTF is
not to be trusted and mark the subprogram unreliable, which happens when
compiler optimizations remove arguments from a static function or when a
mismatched type is passed to a global one. From that point on the
verifier falls back to conservative, R0-only, semantics for the
subprogram, while the compiled code keeps returning a pair and leaves
the upper half in R2 behind the verifier's back.
Rather than silently mistracking R2, reject a return value larger than
8 bytes as soon as the prototype it was derived from becomes unreliable.
Add subprog_ret_pair_unreliable() and test it at the two places that can
observe the flag: check_func_call(), for the call itself, and
prepare_func_exit(), for the return from an inlined static subprogram.
Note that the main program needs no such check: a >8 byte return from
subprog 0 is rejected at BPF_EXIT regardless of whether its BTF is
reliable. Callbacks need none either: a callback address only becomes a
PTR_TO_FUNC through check_ld_imm(), which already rejects any callback
returning more than 8 bytes.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
---
kernel/bpf/verifier.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 41c47bcc3b0a..a01c8ecd9073 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -438,6 +438,21 @@ static void bpf_compute_subprog_ret_regs(struct bpf_verifier_env *env)
}
}
+/*
+ * A >8 byte BPF return changes the calling convention to R0:R2, so the
+ * verifier can only allow it while the subprogram's prototype remains
+ * reliable. Once BTF is marked unreliable, reject the feature instead of
+ * silently falling back to R0-only semantics.
+ */
+static bool subprog_ret_pair_unreliable(struct bpf_verifier_env *env, int subprog)
+{
+ struct bpf_prog_aux *aux = env->prog->aux;
+
+ return bpf_ret_reg_pair(env, subprog) &&
+ aux->func_info_aux &&
+ aux->func_info_aux[subprog].unreliable;
+}
+
static const char *subprog_name(const struct bpf_verifier_env *env, int subprog)
{
struct bpf_func_info *info;
@@ -9459,6 +9474,11 @@ static int check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
err = btf_check_subprog_call(env, subprog, caller->regs);
if (err == -EFAULT)
return err;
+ if (subprog_ret_pair_unreliable(env, subprog)) {
+ verbose(env, "Func#%d ('%s') returns >8 bytes, which requires reliable BTF\n",
+ subprog, subprog_name(env, subprog));
+ return -EINVAL;
+ }
if (bpf_subprog_is_global(env, subprog)) {
const char *sub_name = subprog_name(env, subprog);
@@ -9832,6 +9852,11 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
callee = state->frame[state->curframe];
r0 = &callee->regs[BPF_REG_0];
+ if (subprog_ret_pair_unreliable(env, callee->subprogno)) {
+ verbose(env, "Func#%d ('%s') returns >8 bytes, which requires reliable BTF\n",
+ callee->subprogno, subprog_name(env, callee->subprogno));
+ return -EINVAL;
+ }
nregs = bpf_ret_reg_pair(env, callee->subprogno) ? 2 : 1;
if (nregs > 1)
env->prog->jit_required = 1;
--
2.53.0-Meta
next prev parent reply other threads:[~2026-08-08 19:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 19:03 [PATCH bpf-next v3 00/13] bpf: Support aggregate return values up to 16 bytes Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 01/13] bpf: Factor check_global_ret_scalar_reg() out of the global return check Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 02/13] bpf: Add helpers to describe the R0:R2 return register pair Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 03/13] bpf: Wire up JIT support for 16-byte kfunc returns Yonghong Song
2026-08-08 19:39 ` sashiko-bot
2026-08-10 16:29 ` Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 04/13] bpf: Track R2 of register-pair returns in precision backtracking Yonghong Song
2026-08-08 19:29 ` sashiko-bot
2026-08-10 16:30 ` Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 05/13] bpf: Account R2 of register-pair returns in live register analysis Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 06/13] bpf: Reject callbacks returning more than 8 bytes Yonghong Song
2026-08-08 19:45 ` sashiko-bot
2026-08-10 16:36 ` Yonghong Song
2026-08-08 19:03 ` [PATCH bpf-next v3 07/13] bpf: Add verifier support for 16-byte returns in R0:R2 Yonghong Song
2026-08-08 19:41 ` sashiko-bot
2026-08-10 16:44 ` Yonghong Song
2026-08-08 19:04 ` Yonghong Song [this message]
2026-08-08 19:04 ` [PATCH bpf-next v3 09/13] bpf: Enable aggregate return types up to 16 bytes Yonghong Song
2026-08-08 19:04 ` [PATCH bpf-next v3 10/13] selftests/bpf: Add C tests for 16-byte returns in R0:R2 Yonghong Song
2026-08-08 19:27 ` sashiko-bot
2026-08-10 16:51 ` Yonghong Song
2026-08-08 19:04 ` [PATCH bpf-next v3 11/13] selftests/bpf: Add inline-asm and subprog tests for R0:R2 returns Yonghong Song
2026-08-08 19:04 ` [PATCH bpf-next v3 12/13] selftests/bpf: Add tests for callbacks returning more than 8 bytes Yonghong Song
2026-08-08 19:04 ` [PATCH bpf-next v3 13/13] Documentation/bpf: Document up to 16-byte kfunc return values in R0:R2 Yonghong Song
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=20260808190403.1900396-1-yonghong.song@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.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.