CVE-2026-31413

Vulnerability

Analysis

Root

Cause

The maybe_fork_scalars() function in the BPF verifier is called for both BPF_AND and BPF_OR operations when the source operand is a constant. When the destination register has a signed range of [-1, 0], the function forks the verifier state: one path sets dst = 0, the other dst = -1. This fork is correct for BPF_AND because 0 & K == 0 and -1 & K == K. However, for BPF_OR, the logic is flawed: 0 | K == K, not 0. The pushed path erroneously tracks dst = 0 when the runtime value is actually K, causing a verifier/runtime divergence.

Exploitation

An attacker with the ability to load a crafted BPF program can exploit this unsound scalar forking. No special privileges beyond CAP_BPF (or equivalent) are required; the attacker can manipulate register values to trigger the BPF_OR path with a constant source and a destination register in the [-1, 0] range. The verifier then concludes that dst = 0 on one path, while the actual runtime value is K. This mismatch allows the attacker to bypass the verifier's safety checks, leading to out-of-bounds map reads or writes.

Impact

Successful exploitation enables an attacker to read or write beyond the bounds of a BPF map, potentially leaking sensitive kernel memory or corrupting kernel data structures. This could lead to privilege escalation or other exploits. The vulnerability is rated HIGH with a CVSS v3 score of 7.8.

Mitigation

The fix, confirmed in multiple stable kernel commits [1][2][3][4], ensures that the pushed path re-executes the ALU instruction with dst = 0 by passing env->insn_idx instead of env->insn_idx + 1 to push_stack(). This allows the verifier to compute the correct result for BPF_OR. Users are advised to update their kernel to the latest stable version containing this patch.