CVE-2026-93135
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
On certain Linux systems a network or tracing feature can crash the entire machine if a special optimization is turned off, so the bug must be fixed or the optimization kept enabled to avoid sudden shutdowns.
- Exploitation
- Local Privilege
- Attacker needs
- High Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
When BPF JIT inlining of helper calls is active on architectures such as ARM64, RISC-V or LoongArch, the verifier omits offset rewriting; if the JIT is later unavailable the interpreter dereferences the raw helper enum as a function pointer and crashes with an alignment fault or kernel panic.
Why it matters to the business
Systems that disable or cannot guarantee the BPF JIT may experience unrecoverable kernel crashes when certain network or tracing programs are loaded, leading to service outages and forced reboots.
How an attack unfolds
An attacker with the ability to load a BPF program (via unprivileged or privileged interfaces) submits a program that triggers JIT inlining on a supported architecture; at runtime, if net.core.bpf_jit_enable is 0 or JIT compilation fails, the interpreter executes the malformed instruction and panics the kernel.
How to fix it
Upgrade to a kernel containing the fix that sets prog->jit_required = 1 for such programs; ensure net.core.bpf_jit_enable remains enabled on affected architectures or restrict unprivileged BPF loading.
How to confirm the fix worked
Confirm the presence of the jit_required assignment in the verifier path for inlined helpers; attempt to load an affected program with JIT disabled and verify the load is rejected rather than causing a panic.
Typical attack path
- Identify a target system running a vulnerable kernel with BPF JIT disabled or unreliable.
- Craft or obtain a BPF program containing helper calls that the JIT would normally inline.
- Load the program through an allowed interface (e.g., bpf syscall).
- Trigger interpreter fallback to cause the panic.
How to detect it
Inspect kernel logs for alignment faults or panic messages referencing __bpf_call_base immediately after BPF program loads; correlate with audit records of bpf syscalls from unprivileged users.
What your security team should do
- Apply the upstream fix immediately on all kernels supporting BPF JIT inlining.
- Audit systems where bpf_jit_enable is set to 0 and either enable it or block unprivileged BPF use.
- Monitor for kernel oops/panic logs containing __bpf_call_base during BPF program loads.
The record
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 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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|