CVE-2026-31413

What it actually does

The BPF verifier's maybe_fork_scalars() function incorrectly forks scalar state for BPF_OR when the destination register holds the signed range [-1, 0], causing the pushed path to track dst as 0 while the runtime value is actually K; this verifier/runtime divergence permits out-of-bounds BPF map accesses.

Why it matters to the business

Local attackers on Linux systems can achieve memory corruption leading to privilege escalation or system instability, impacting the security of any environment relying on unpatched kernels with BPF programs.

How an attack unfolds

An attacker loads a crafted BPF program containing an ALU BPF_OR instruction where the destination register's tracked range is [-1, 0]; the flawed forking logic in maybe_fork_scalars() produces an incorrect verifier state on the pushed path, allowing subsequent map accesses that exceed allocated bounds at runtime.

How to fix it

Apply the upstream kernel fix that changes the push_stack() call in maybe_fork_scalars() to pass env->insn_idx instead of env->insn_idx + 1 so the pushed path correctly re-evaluates the ALU instruction; upgrade to a kernel release containing this commit.

How to confirm the fix worked

Verify the presence of the corrected push_stack() argument in the kernel source; confirm that BPF verifier tests covering BPF_OR with negative scalar ranges now produce consistent results; test crafted programs no longer permit out-of-bounds map accesses.

Typical attack path

1. Compile and load a BPF program via bpf() syscall that exercises BPF_OR with a constant source operand and dst range [-1, 0]
2. Trigger verifier state forking via maybe_fork_scalars()
3. Perform map lookup or update operations that the verifier accepts but that read or write beyond the map bounds at runtime
4. Escalate privileges or cause denial of service via the resulting memory corruption

How to detect it

Review kernel audit logs and BPF verifier error messages for unexpected scalar forking behavior; inspect loaded BPF programs for ALU_OR instructions paired with registers that can hold negative values; look for runtime map access violations or oops reports referencing bpf_map areas.

What your security team should do

• Prioritize kernel upgrades on all systems that compile or run untrusted BPF programs
• Monitor upstream stable branches for backported fixes given the kernel's high ecosystem prevalence
• Restrict unprivileged BPF loading via sysctl until patches are deployed