From: Leon Hwang <leon.hwang@linux.dev>
To: Vincent Thiberville <vincent@harfanglab.fr>,
"ast@kernel.org" <ast@kernel.org>,
"daniel@iogearbox.net" <daniel@iogearbox.net>
Cc: "bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: PROBLEM: BPF interpreter fallback after JIT compilation of BPF_ADDR_PERCPU leads to kernel panic
Date: Wed, 1 Jul 2026 10:49:03 +0800 [thread overview]
Message-ID: <90c32de0-feac-4e63-9757-2a1d115be08c@linux.dev> (raw)
In-Reply-To: <MR1P264MB33143D31DA8982ADB2E0D808B7F72@MR1P264MB3314.FRAP264.PROD.OUTLOOK.COM>
On 30/6/26 20:08, Vincent Thiberville wrote:
> Hello
>
> Thank you for the quick feedback. I cannot reproduce the issue using my reproducer on bpf-next, nor on 7.1.0-rc1. However, as I said, it works on 6.12.74 and on 7.0.13.
>
> My best guess would be that a patch like this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3e945223e0158c85dbde23de4f89493a2a817f6 makes the reproducer no longer work, but I do not know.
> I don't know if this means the bug is no longer reachable on kernels >=7.1, or if my reproducer no longer works but the bug is reachable with other setups.
>
> To the best of my understanding however, the reproducer should work between (and including) 6.10 and 7.0. I have not tested to find the exact version bounds however.
>
> Best Regards
> Vincent
>
Pls do not top-post. And reply in plain text mode.
See
https://docs.kernel.org/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions.
[...]
>>
>>
>> *
>> Call bpf_map_lookup_elem (1)
>> *
>> Dereference the result if non null (2)
>> *
>> Jump with a large enough offset (>=11000) over instructions using constants (3)
>>
>> ```
>> 0: .......... (62) *(u32 *)(r10 -4) = 0
>> 1: .......... (bf) r2 = r10
>> 2: ..2....... (07) r2 += -4
>> 3: ..2....... (18) r1 = 0xffff8f0708cca200
>> 5: .12....... (85) call bpf_map_lookup_elem#1
>> 6: 0......... (15) if r0 == 0x0 goto pc+1
>> 7: 0......... (79) r0 = *(u64 *)(r0 +0)
>> 8: .......... (b7) r0 = 0
- 190 │ prog[8] = BPF_MOV64_IMM(BPF_REG_0, 0);
+ 190 │ prog[8] = BPF_JMP_IMM(BPF_IMM, 0, 0, 0);
By changing 'r0 = 0' to nop, I can reproduce the BUG with bpf-next code:
[ 742.666733] BUG: unable to handle page fault for address:
0000339b72aa42b8
[ 742.667846] #PF: supervisor read access in kernel mode
[ 742.ogr6a6m8595] # PiFs INT:E RePrRror_code(0x0000) - not-present page
With this diff, the internal BPF_ADDR_PERCPU insn is supported in the
interpreter.
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 6b28c8641b26..d0672f1ea1b1 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1918,6 +1918,9 @@ static u64 ___bpf_prog_run(u64 *regs, const struct
bpf_insn *insn)
case 32:
DST = (s32) SRC;
break;
+ case BPF_ADDR_PERCPU:
+ DST = (unsigned long)raw_cpu_ptr((void __percpu
*)(unsigned long)SRC);
+ break;
}
CONT;
ALU64_MOV_K:
The reproducer cannot crash the kernel after fixing.
./bpf-interpreter-bug
BPF_ADDR_PERCPU JIT bug reproducer
WARNING: this WILL crash the kernel. Run in a disposable VM.
Current config: bpf_jit_enable=1 bpf_jit_harden=2 bpf_jit_limit=528482304
Created per-cpu array map (fd 3)
Loaded target BPF program (fd 4)
Verifier:
processed 11012 insns (limit 1000000) max_states_per_insn 0 total_states
2 peak_states 2 mark_read 0
insn 10893 cannot be patched due to 16-bit range
BPF program is INTERPRETED (JIT failed as expected)
Sending UDP packet to trigger the BPF program...
If the bug is present, the kernel crashes NOW.
No crash — The kernel is either too old or has a fix.
Thanks,
Leon
prev parent reply other threads:[~2026-07-01 2:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:42 PROBLEM: BPF interpreter fallback after JIT compilation of BPF_ADDR_PERCPU leads to kernel panic Vincent Thiberville
2026-06-30 1:48 ` Leon Hwang
2026-06-30 12:08 ` Vincent Thiberville
2026-07-01 2:49 ` Leon Hwang [this message]
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=90c32de0-feac-4e63-9757-2a1d115be08c@linux.dev \
--to=leon.hwang@linux.dev \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=vincent@harfanglab.fr \
/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.