[PATCH bpf-next v9 0/2] Introduce jit_required to prevent a kernel panic

[PATCH bpf-next v9 0/2] Introduce jit_required to prevent a kernel panic

[Tiezhu Yang]

This series introduces a 'jit_required' flag in struct bpf_prog
to track programs that strictly require JIT.

The aim is to prevent a kernel panic by rejecting programs with
inlined helpers when JIT is not available.

v8 -> v9:
  -- Initialize 'fp->jit_required' with
     'IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON)'
     in bpf_prog_alloc_no_stats()
  -- Simplify __bpf_prog_select_runtime()
  -- Simplify the commit description for patch 1
  -- Enhance the commit description for patch 2

Tiezhu Yang (2):
  bpf: Introduce jit_required flag and remove bpf_prog_has_kfunc_call()
  bpf: Reject programs with inlined helpers if JIT is not available

 include/linux/bpf.h   | 9 ++-------
 kernel/bpf/core.c     | 7 ++-----
 kernel/bpf/fixups.c   | 9 +++++----
 kernel/bpf/verifier.c | 7 ++-----
 4 files changed, 11 insertions(+), 21 deletions(-)

-- 
2.42.0

[PATCH bpf-next v9 1/2] bpf: Introduce jit_required flag and remove bpf_prog_has_kfunc_call()

[Tiezhu Yang]

Introduce a 'jit_required' bitfield flag in struct bpf_prog to track
whether a BPF program strictly requires the JIT compiler to run. This
prevents a dangerous runtime fallback to the interpreter for features
that are only implemented in the JIT compiler.

Currently, bpf_prog_has_kfunc_call() is used only for kernel function
calls, replace the kfunc-specific helper with the new 'jit_required'
flag. This makes it easy to support other JIT-only BPF features, such
as inlined helpers.

Suggested-by: Alexei Starovoitov <ast@kernel.org>
Suggested-by: KaFai Wan <kafai.wan@linux.dev>
Suggested-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 include/linux/bpf.h   | 9 ++-------
 kernel/bpf/core.c     | 7 ++-----
 kernel/bpf/fixups.c   | 5 ++---
 kernel/bpf/verifier.c | 7 ++-----
 4 files changed, 8 insertions(+), 20 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index adf53f7edf28..b1271f53905c 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1865,8 +1865,9 @@ struct bpf_prog_aux {
 
 struct bpf_prog {
 	u16			pages;		/* Number of allocated pages */
-	u16			jited:1,	/* Is our filter JIT'ed? */
+	u32			jited:1,	/* Is our filter JIT'ed? */
 				jit_requested:1,/* archs need to JIT the prog */
+				jit_required:1,	/* program strictly requires JIT compiler */
 				gpl_compatible:1, /* Is filter GPL compatible? */
 				cb_access:1,	/* Is control block accessed? */
 				dst_needed:1,	/* Do we need dst entry? */
@@ -3170,7 +3171,6 @@ const struct bpf_func_proto *bpf_base_func_proto(enum bpf_func_id func_id,
 						 const struct bpf_prog *prog);
 void bpf_task_storage_free(struct task_struct *task);
 void bpf_cgrp_storage_free(struct cgroup *cgroup);
-bool bpf_prog_has_kfunc_call(const struct bpf_prog *prog);
 const struct btf_func_model *
 bpf_jit_find_kfunc_model(const struct bpf_prog *prog,
 			 const struct bpf_insn *insn);
@@ -3509,11 +3509,6 @@ static inline void bpf_task_storage_free(struct task_struct *task)
 {
 }
 
-static inline bool bpf_prog_has_kfunc_call(const struct bpf_prog *prog)
-{
-	return false;
-}
-
 static inline const struct btf_func_model *
 bpf_jit_find_kfunc_model(const struct bpf_prog *prog,
 			 const struct bpf_insn *insn)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 6e19a030da6f..883cb7a800b1 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -126,6 +126,7 @@ struct bpf_prog *bpf_prog_alloc_no_stats(unsigned int size, gfp_t gfp_extra_flag
 	fp->aux->main_prog_aux = aux;
 	fp->aux->prog = fp;
 	fp->jit_requested = ebpf_jit_enabled();
+	fp->jit_required = IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON);
 	fp->blinding_requested = bpf_jit_blinding_enabled(fp);
 #ifdef CONFIG_CGROUP_BPF
 	aux->cgroup_atype = CGROUP_BPF_ATTACH_TYPE_INVALID;
@@ -2670,15 +2671,11 @@ struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct
 	/* In case of BPF to BPF calls, verifier did all the prep
 	 * work with regards to JITing, etc.
 	 */
-	bool jit_needed = false;
+	bool jit_needed = fp->jit_required;
 
 	if (fp->bpf_func)
 		goto finalize;
 
-	if (IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) ||
-	    bpf_prog_has_kfunc_call(fp))
-		jit_needed = true;
-
 	if (!bpf_prog_select_interpreter(fp))
 		jit_needed = true;
 
diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
index 12a8a4eb757f..02246df2f6c3 100644
--- a/kernel/bpf/fixups.c
+++ b/kernel/bpf/fixups.c
@@ -1378,7 +1378,6 @@ int bpf_fixup_call_args(struct bpf_verifier_env *env)
 #ifndef CONFIG_BPF_JIT_ALWAYS_ON
 	struct bpf_prog *prog = env->prog;
 	struct bpf_insn *insn = prog->insnsi;
-	bool has_kfunc_call = bpf_prog_has_kfunc_call(prog);
 	int depth;
 #endif
 	int i, err = 0;
@@ -1404,8 +1403,8 @@ int bpf_fixup_call_args(struct bpf_verifier_env *env)
 			return err;
 	}
 #ifndef CONFIG_BPF_JIT_ALWAYS_ON
-	if (has_kfunc_call) {
-		verbose(env, "calling kernel functions are not allowed in non-JITed programs\n");
+	if (prog->jit_required) {
+		verbose(env, "program requires BPF JIT compiler but it is not available\n");
 		return -EINVAL;
 	}
 	for (i = 0; i < env->subprog_cnt; i++) {
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 51f7965d42e3..1e178143e10b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2714,6 +2714,8 @@ int bpf_add_kfunc_call(struct bpf_verifier_env *env, u32 func_id, u16 offset)
 		prog_aux->kfunc_tab = tab;
 	}
 
+	env->prog->jit_required = 1;
+
 	/* func_id == 0 is always invalid, but instead of returning an error, be
 	 * conservative and wait until the code elimination pass before returning
 	 * error, so that invalid calls that get pruned out can be in BPF programs
@@ -2768,11 +2770,6 @@ int bpf_add_kfunc_call(struct bpf_verifier_env *env, u32 func_id, u16 offset)
 	return 0;
 }
 
-bool bpf_prog_has_kfunc_call(const struct bpf_prog *prog)
-{
-	return !!prog->aux->kfunc_tab;
-}
-
 static int add_subprog_and_kfunc(struct bpf_verifier_env *env)
 {
 	struct bpf_subprog_info *subprog = env->subprog_info;
-- 
2.42.0

[PATCH bpf-next v9 2/2] bpf: Reject programs with inlined helpers if JIT is not available

[Tiezhu Yang]

When an architecture (such as LoongArch, ARM64, and RISC-V) implements
bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper
call offset (insn->imm) in bpf_do_misc_fixups(). This is because the
helper is expected to be inlined by the JIT compiler later. Therefore,
insn->imm remains as the raw helper enum ID.

However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
if JIT compilation fails dynamically (e.g., due to OOM), the program
falls back to the BPF interpreter.

When the interpreter executes (__bpf_call_base + insn->imm) with the
unpatched raw ID, it jumps into an invalid address space, triggering
an instruction alignment fault or a kernel panic.

Although these helpers have valid C implementations in the kernel, the
omission of offset rewriting makes runtime interpreter fallback fatal.

Fix this by setting 'prog->jit_required = 1' when helper call rewriting
is skipped for JIT inlining. This ensures that such programs are safely
rejected if JIT is not available, preventing the runtime kernel panic.

Fixes: 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()")
Suggested-by: Alexei Starovoitov <ast@kernel.org>
Suggested-by: KaFai Wan <kafai.wan@linux.dev>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 kernel/bpf/fixups.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
index 02246df2f6c3..d3be972714b2 100644
--- a/kernel/bpf/fixups.c
+++ b/kernel/bpf/fixups.c
@@ -1840,8 +1840,10 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
 		}
 
 		/* Skip inlining the helper call if the JIT does it. */
-		if (bpf_jit_inlines_helper_call(insn->imm))
+		if (bpf_jit_inlines_helper_call(insn->imm)) {
+			prog->jit_required = 1;
 			goto next_insn;
+		}
 
 		if (insn->imm == BPF_FUNC_get_route_realm)
 			prog->dst_needed = 1;
-- 
2.42.0

Re: [PATCH bpf-next v9 2/2] bpf: Reject programs with inlined helpers if JIT is not available

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

> When an architecture (such as LoongArch, ARM64, and RISC-V) implements
> bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper
> call offset (insn->imm) in bpf_do_misc_fixups(). This is because the
> helper is expected to be inlined by the JIT compiler later. Therefore,
> insn->imm remains as the raw helper enum ID.
>
> However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
> if JIT compilation fails dynamically (e.g., due to OOM), the program
> falls back to the BPF interpreter.
>
> When the interpreter executes (__bpf_call_base + insn->imm) with the
> unpatched raw ID, it jumps into an invalid address space, triggering
> an instruction alignment fault or a kernel panic.
>
> Although these helpers have valid C implementations in the kernel, the
> omission of offset rewriting makes runtime interpreter fallback fatal.
>
> Fix this by setting 'prog->jit_required = 1' when helper call rewriting
> is skipped for JIT inlining. This ensures that such programs are safely
> rejected if JIT is not available, preventing the runtime kernel panic.

The commit message gives two reasons for the interpreter fallback:

> However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
> if JIT compilation fails dynamically (e.g., due to OOM), the program
> falls back to the BPF interpreter.

Is the "fails dynamically (e.g., due to OOM)" part accurate?

The JIT decision looks like it is settled before verification runs:
bpf_prog_alloc_no_stats() sets fp->jit_requested ahead of the bpf_check()
call in bpf_prog_load(), so the choice between JIT and interpreter appears
to be made at load time rather than changing after a dynamic JIT failure.

> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
> index 02246df2f6c3..d3be972714b2 100644
> --- a/kernel/bpf/fixups.c
> +++ b/kernel/bpf/fixups.c
> @@ -1840,8 +1840,10 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
>  		}
>
>  		/* Skip inlining the helper call if the JIT does it. */
> -		if (bpf_jit_inlines_helper_call(insn->imm))
> +		if (bpf_jit_inlines_helper_call(insn->imm)) {
> +			prog->jit_required = 1;
>  			goto next_insn;
> +		}

If the JIT decision is final at load time, would gating on
bpf_jit_inlines_helper_call() together with the jit-enabled state be
enough here, without depending on the dynamic-failure rationale?

This point was raised during review of an earlier version of the series
and does not appear to have been answered before this version, and the
disputed wording is still present in the commit message.


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28935824036

Re: [PATCH bpf-next v9 0/2] Introduce jit_required to prevent a kernel panic

[Leon Hwang]

On 2026/7/8 18:18, Tiezhu Yang wrote:
> This series introduces a 'jit_required' flag in struct bpf_prog
> to track programs that strictly require JIT.
> 
> The aim is to prevent a kernel panic by rejecting programs with
> inlined helpers when JIT is not available.


lgtm,

Acked-by: Leon Hwang <leon.hwang@linux.dev>


Beyond this fix and the other assorted interpreter fallback issues [1],
I think it's time to come up with a plan to retire the interpreter,
given that it's considered a security hole. I'll post an RFC on
interpreter retirement in the near future.

[1] https://lore.kernel.org/bpf/20260626154330.33619-1-leon.hwang@linux.dev/

Thanks,
Leon

> [...]

Re: [PATCH bpf-next v9 2/2] bpf: Reject programs with inlined helpers if JIT is not available

[Tiezhu Yang]

On 2026/7/8 下午6:59, bot+bpf-ci@kernel.org wrote:
>> When an architecture (such as LoongArch, ARM64, and RISC-V) implements
>> bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper
>> call offset (insn->imm) in bpf_do_misc_fixups(). This is because the
>> helper is expected to be inlined by the JIT compiler later. Therefore,
>> insn->imm remains as the raw helper enum ID.
>>
>> However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
>> if JIT compilation fails dynamically (e.g., due to OOM), the program
>> falls back to the BPF interpreter.
>>
>> When the interpreter executes (__bpf_call_base + insn->imm) with the
>> unpatched raw ID, it jumps into an invalid address space, triggering
>> an instruction alignment fault or a kernel panic.
>>
>> Although these helpers have valid C implementations in the kernel, the
>> omission of offset rewriting makes runtime interpreter fallback fatal.
>>
>> Fix this by setting 'prog->jit_required = 1' when helper call rewriting
>> is skipped for JIT inlining. This ensures that such programs are safely
>> rejected if JIT is not available, preventing the runtime kernel panic.
> 
> The commit message gives two reasons for the interpreter fallback:
> 
>> However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
>> if JIT compilation fails dynamically (e.g., due to OOM), the program
>> falls back to the BPF interpreter.
> 
> Is the "fails dynamically (e.g., due to OOM)" part accurate?
> 
> The JIT decision looks like it is settled before verification runs:
> bpf_prog_alloc_no_stats() sets fp->jit_requested ahead of the bpf_check()
> call in bpf_prog_load(), so the choice between JIT and interpreter appears
> to be made at load time rather than changing after a dynamic JIT failure.
> 
>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index 02246df2f6c3..d3be972714b2 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
>> @@ -1840,8 +1840,10 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
>>   		}
>>
>>   		/* Skip inlining the helper call if the JIT does it. */
>> -		if (bpf_jit_inlines_helper_call(insn->imm))
>> +		if (bpf_jit_inlines_helper_call(insn->imm)) {
>> +			prog->jit_required = 1;
>>   			goto next_insn;
>> +		}
> 
> If the JIT decision is final at load time, would gating on
> bpf_jit_inlines_helper_call() together with the jit-enabled state be
> enough here, without depending on the dynamic-failure rationale?
> 
> This point was raised during review of an earlier version of the series
> and does not appear to have been answered before this version, and the
> disputed wording is still present in the commit message.

I tested on a real hardware (Loongson-3A6000 physical machine).

Only with the first patch and without this second patch,
keep net.core.bpf_jit_enable=1, simulate a dynamic JIT
failure like this:

```
diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
index 2738b4db1165..fa56a593ac1a 100644
--- a/arch/loongarch/net/bpf_jit.c
+++ b/arch/loongarch/net/bpf_jit.c
@@ -2208,7 +2208,7 @@ struct bpf_prog *bpf_int_jit_compile(struct 
bpf_verifier_env *env, struct bpf_pr
          * If BPF JIT was not enabled then we must fall back to
          * the interpreter.
          */
-       if (!prog->jit_requested)
+       if (prog->jit_requested)
                 return prog;

         jit_data = prog->aux->jit_data;
```

CONFIG_BPF_JIT_ALWAYS_ON is disabled, the kernel panics.

Here are the test logs:

```
fedora@linux:~$ cat test_panic.c
   #include <linux/bpf.h>
   #include <bpf/bpf_helpers.h>

   SEC("kprobe/sys_getpid")
   int test_panic(void *ctx)
   {
   	struct task_struct *task;

   	task = (struct task_struct *)bpf_get_current_task_btf();
   	if (task)
   		bpf_printk("Task address: %p\n", task);

   	return 0;
   }

   char LICENSE[] SEC("license") = "GPL";
fedora@linux:~$ clang -target bpf -O2 -g -c test_panic.c -o test_panic.o
fedora@linux:~$ sudo sysctl -w net.core.bpf_jit_enable=1
net.core.bpf_jit_enable = 1
fedora@linux:~$ sudo bpftool prog load test_panic.o 
/sys/fs/bpf/test_panic autoattach
fedora@linux:~$ sudo cat /sys/kernel/debug/tracing/trace_pipe
Segmentation fault

[  662.150034] Kernel ade access[#1]:
[  662.153416] CPU: 5 UID: 0 PID: 1224 Comm: (udev-worker) Not tainted 
7.2.0-rc1bpf+ #7 PREEMPT(full)
[  662.162408] Hardware name: Loongson 
Loongson-3A6000-7A2000-1w-V0.1-EVB/Loongson-3A6000-7A2000-1w-EVB-V1.21, 
BIOS Loongson-UDK2018-V4.0.05878.1-stable20241
[  662.176149] pc 9000000000f6a02e ra 9000000000f6ba70 tp 
9000000122539000 sp 900000015ef33ad0
[  662.184447] a0 900000015ef33d20 a1 0000000000000000 a2 
0000000000000000 a3 0000000000000000
[  662.192745] a4 0000000000000000 a5 00007ffffb7ebe4b a6 
00007ffffb7ebe4b a7 00000000000000ac
[  662.201044] t0 9000000000f6a02e t1 000000000000009e t2 
c1cd71039fc4e000 t3 00000000000000f4
[  662.209342] t4 900000016ebcdb00 t5 9000000122539000 t6 
0000000000000000 t7 0000000000ff0100
[  662.217640] t8 900000015ef33e60 u0 00000004749f0000 s9 
900000015ef33ec0 s0 ffff800032be0060
[  662.225938] s1 0000000000000051 s2 00000000000000f1 s3 
0000000000000040 s4 0000000000000000
[  662.234236] s5 900000015ef33b40 s6 9000000003520148 s7 
900000012218f9d0 s8 0000000000000000
[  662.242534]    ra: 9000000000f6ba70 ___bpf_prog_run+0x1370/0x36b0
[  662.248590]   ERA: 9000000000f6a02e __traceiter_xdp_exception+0x4e/0x90
[  662.255161]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[  662.261307]  PRMD: 00000004 (PPLV0 +PIE -PWE)
[  662.265633]  EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
[  662.270392]  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
[  662.275150] ESTAT: 00080000 [ADEF] (IS= ECode=8 EsubCode=0)
[  662.280686]  BADV: 9000000000f6a02e
[  662.284146]  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)
```

The root cause can be easily seen in `__bpf_prog_select_runtime()`
after only applying patch 1:

1. Without patch 2, `fp->jit_required` remains `false` for programs
    using JIT-inlined helpers, so `jit_needed` initializes to `false`.
2. When the JIT compiler fails dynamically (returning `!fp->jited`),
    the program incorrectly falls back to the interpreter.

Thus the following conditions are not matched in
`__bpf_prog_select_runtime()`:

                 if (!fp->jited && jit_needed) {
                         *err = -ENOTSUPP;
                         return fp;
                 }

`!fp->jited` is true, but `jit_needed` is false.

3. As a result, the program incorrectly falls back to the interpreter
with unpatched instruction raw IDs, causing the fatal kernel panic.

IMO, there is no problem in the commit message.

Thanks,
Tiezhu

Re: [PATCH bpf-next v9 0/2] Introduce jit_required to prevent a kernel panic

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Eduard Zingerman <eddyz87@gmail.com>:

On Wed,  8 Jul 2026 18:18:04 +0800 you wrote:
> This series introduces a 'jit_required' flag in struct bpf_prog
> to track programs that strictly require JIT.
> 
> The aim is to prevent a kernel panic by rejecting programs with
> inlined helpers when JIT is not available.
> 
> v8 -> v9:
>   -- Initialize 'fp->jit_required' with
>      'IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON)'
>      in bpf_prog_alloc_no_stats()
>   -- Simplify __bpf_prog_select_runtime()
>   -- Simplify the commit description for patch 1
>   -- Enhance the commit description for patch 2
> 
> [...]

Here is the summary with links:
  - [bpf-next,v9,1/2] bpf: Introduce jit_required flag and remove bpf_prog_has_kfunc_call()
    https://git.kernel.org/bpf/bpf-next/c/9a6df65d5c6a
  - [bpf-next,v9,2/2] bpf: Reject programs with inlined helpers if JIT is not available
    https://git.kernel.org/bpf/bpf-next/c/f1c27922576e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html