CVE-2026-93135: bpf: Reject programs with inlined helpers if JIT is not available
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject programs with inlined helpers if JIT is not available
When an architecture (such as LoongArch, ARM64, and RISC-V) implements bpfjitinlineshelpercall(), the verifier skips rewriting the helper call offset (insn->imm) in bpfdomiscfixups(). 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.bpfjitenable=0) or if JIT compilation fails dynamically (e.g., due to OOM), the program falls back to the BPF interpreter.
When the interpreter executes (bpfcallbase + 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->jitrequired = 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
If BPF JIT is disabled at runtime (net.core.bpf_jit_enable=0), ensure affected BPF programs are rejected/blocked when they rely on inlined helpers, rather than allowing interpreter fallback that can trigger a kernel panic.
Linux kernel BPF JIT net.core.bpf_jit_enable = 0 - Configuration
When helper call rewriting is performed, set 'prog->jit_required = 1' so that programs requiring JIT inlining are flagged accordingly (bpf: Reject programs with inlined helpers if JIT is not available).
Linux kernel BPF helper rewriting prog->jit_required = 1
Event History
Frequently Asked Questions
Which systems are exposed to this failure mode?
Systems are exposed when their architecture implements bpf_jit_inlines_helper_call(), including examples named as LoongArch, ARM64, and RISC-V, and they run BPF programs containing helper calls expected to be inlined by JIT.
What conditions trigger the crash?
The affected BPF program must fall back to the interpreter after helper-call offset rewriting was skipped. This can occur when JIT is disabled at runtime through net.core.bpf_jit_enable=0 or when JIT compilation fails dynamically, such as from out-of-memory conditions.
What is the impact when the vulnerable path is reached?
The interpreter uses an unpatched raw helper ID as an address offset and can jump into invalid address space. This can cause an instruction-alignment fault or a kernel panic.
What mitigation is available if the fix cannot be deployed immediately?
Avoid interpreter fallback for affected programs by keeping BPF JIT available and enabled, and avoid conditions that cause JIT compilation to fail, such as out-of-memory situations. The resolved behavior instead rejects these programs when JIT is unavailable.