Linux Kernel CVE-2026-31526

Exploitation requires: (1) unprivileged BPF enabled (kernel.unprivileged_bpf_disabled=0) or CAP_BPF capability; (2) ability to load eBPF bytecode via bpf() syscall (not restricted by SELinux/AppArmor); (3) BPF program must contain a static subprogram (not a main program) that acquires active_rcu_locks, active_preempt_locks, or active_irq_id before calling bpf_throw(). The vulnerability does NOT affect spin_lock cases because those are validated before bpf_throw executes. Non-exploitable scenarios: kernel builds with CONFIG_BPF=n or CONFIG_BPF_JIT=n disable BPF entirely; systems with kernel.unprivileged_bpf_disabled=1 prevent unauthorized BPF loading; SELinux/AppArmor policies restricting bpf() syscall; systems running unaffected kernel versions (pre-6.7 or post-6.18.21/6.19.11/7.0). This is fundamentally a verifier bypass, not a memory corruption or authentication escape.

The risk assessment reveals a disconnect between CVSS and real-world exploitability. CVSS 5.5 with local attack vector (AV:L/AC:L/PR:L) and availability impact (A:H) indicates a privilege escalation or DoS path requiring local access and standard user privileges. However, EPSS 0.02% (percentile 4%) suggests minimal practical exploitation likelihood. The vulnerability is not listed in CISA KEV, and no public exploit code is referenced. The technical requirements are highly specialized: an attacker must (1) run local BPF programs with CAP_BPF privileges, (2) deliberately craft a subprogram with unmatched RCU/preemption lock acquisition, and (3) trigger bpf_throw() from that subprogram. While the impact (system instability, potential denial of service through sustained lock holding) is real, exploitation requires deliberate malicious BPF bytecode and elevated capabilities. This is a logic bug in a security validator rather than a memory corruption or remote code execution vulnerability. Linux distributions and embedded systems with unprivileged BPF disabled face minimal exposure.

A local attacker with standard user privileges on a system with unprivileged BPF enabled (kernel.unprivileged_bpf_disabled=0) crafts a malicious eBPF program that acquires an RCU read lock or preemption lock within a static subprogram, then invokes bpf_throw() before releasing the lock. When loaded into the kernel via bpf() syscall, the BPF verifier fails to detect the lock mismatch because check_lock validation is skipped for exception exits in subprograms. The program is accepted and at runtime, bpf_throw() unwinds the stack via ORC without releasing the held lock, leaving the kernel in a deadlock or hang condition that forces denial of service.