From: sashiko-bot@kernel.org
To: "Leon Hwang" <leon.hwang@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 02/11] bpf: Disallow interpreter fallback for user BPF_ADDR_SPACE_CAST insn
Date: Mon, 22 Jun 2026 15:07:59 +0000 [thread overview]
Message-ID: <20260622150759.EC9071F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260622143557.22955-3-leon.hwang@linux.dev>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Missing verifier log message for non-JITed programs rejected due to `has_addr_space_cast_insn`.
Pre-existing issues:
- [Critical] Incomplete fix allows BPF interpreter fallback for arena programs, leading to a kernel panic.
--
commit 37ba328d18b1ffa46e00f11cf84efa654fd229ec
Author: Leon Hwang <leon.hwang@linux.dev>
bpf: Disallow interpreter fallback for user BPF_ADDR_SPACE_CAST insn
Since interpreter is unable to handle the 'insn_is_cast_user()' insn,
require JIT in __bpf_prog_select_runtime() when the prog has the insn.
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 649cce41e13f3..49398b5bd172d 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -2620,6 +2620,7 @@ struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct
> goto finalize;
>
> if (IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) ||
> + fp->aux->has_addr_space_cast_insn ||
> bpf_prog_has_kfunc_call(fp))
> jit_needed = true;
[Severity: Medium]
If JIT is disabled or fails, returning -ENOTSUPP here will reject the
program load silently without a verifier log message. Unlike
bpf_prog_has_kfunc_call() which provides a helpful verbose() log in
bpf_fixup_call_args():
if (has_kfunc_call) {
verbose(env, "calling kernel functions are not allowed in non-JITed programs\n");
return -EINVAL;
}
Users encountering this for has_addr_space_cast_insn will not see an
explanation for the EOPNOTSUPP error. Could we add a verifier log message
explaining why JIT is required here?
> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
> index 3cf2cc6e3ab66..2d5958774b61b 100644
> --- a/kernel/bpf/fixups.c
> +++ b/kernel/bpf/fixups.c
> @@ -1523,6 +1523,8 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
> insn->off = 0;
> insn->imm = 0;
> } /* cast from as(0) to as(1) should be handled by JIT */
> + if (insn_is_cast_user(insn))
> + prog->aux->has_addr_space_cast_insn = true;
[Severity: Critical]
This is a pre-existing issue, but the patch attempts to fix interpreter
fallback for BPF_ADDR_SPACE_CAST and fails to address the underlying panic
with arena programs.
If a program uses an arena and obtains a PTR_TO_ARENA without a cast_user
instruction (for instance, using cast_kern), or if the arena map has
BPF_F_NO_USER_CONV set, has_addr_space_cast_insn will not be set.
In the case of BPF_F_NO_USER_CONV, the instruction is rewritten to
BPF_ALU | BPF_MOV | BPF_X right before the insn_is_cast_user() check.
Memory accesses using PTR_TO_ARENA are rewritten by bpf_do_misc_fixups()
to use BPF_PROBE_MEM32 or BPF_PROBE_MEM32SX. If these arena programs fall
back to the interpreter, wouldn't they hit the BUG_ON(1) in ___bpf_prog_run()
because it lacks handlers for these opcodes?
kernel/bpf/core.c:___bpf_prog_run() {
...
default_label:
pr_warn("BPF interpreter: unknown opcode %02x (imm: 0x%x)\n",
insn->code, insn->imm);
BUG_ON(1);
...
}
Should jit_needed be enforced in __bpf_prog_select_runtime() for all
programs using fp->aux->arena instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622143557.22955-1-leon.hwang@linux.dev?part=2
next prev parent reply other threads:[~2026-06-22 15:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 14:35 [PATCH bpf-next v7 00/11] bpf: Introduce global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 01/11] bpf: Drop duplicate blank lines in verifier Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 02/11] bpf: Disallow interpreter fallback for user BPF_ADDR_SPACE_CAST insn Leon Hwang
2026-06-22 15:07 ` sashiko-bot [this message]
2026-06-22 14:35 ` [PATCH bpf-next v7 03/11] bpf: Disallow interpreter fallback for BPF_ADDR_PERCPU insn Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 04/11] bpf: Introduce global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 05/11] libbpf: Probe percpu data feature Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 06/11] libbpf: Add support for global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 07/11] bpftool: Generate skeleton " Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 08/11] selftests/bpf: Add tests to verify " Leon Hwang
2026-06-22 14:57 ` sashiko-bot
2026-06-22 15:24 ` bot+bpf-ci
2026-06-22 14:35 ` [PATCH bpf-next v7 09/11] selftests/bpf: Add test to verify accessing rdonly percpu_array Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 10/11] selftests/bpf: Add tests to verify verifier log for global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 11/11] selftests/bpf: Add test to verify bpf_iter " Leon Hwang
2026-06-22 15:08 ` sashiko-bot
2026-06-22 15:24 ` bot+bpf-ci
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=20260622150759.EC9071F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=leon.hwang@linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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