HIGH Introduced in 6.11
bpf Verifier Bypass
CVE-2026-53081
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.8HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C.
02KernelScan AI Analysis
Risk summary
A flaw in the BPF verifier's state pruning logic allows a crafted BPF program to bypass safety checks by exploiting inconsistent base ID mapping for BPF_ADD_CONST scalar registers. An unprivileged local user (or one with BPF program loading capability) could load a malicious BPF program that the verifier incorrectly deems safe, potentially leading to arbitrary kernel memory read/write and privilege escalation. Systems where unprivileged BPF is enabled are most at risk.
Vulnerability analysis
The vulnerability is a verifier logic bypass in the BPF subsystem's check_scalar_ids() function. When two scalar registers both carry the BPF_ADD_CONST flag (indicating one is derived from another via a constant offset), the verifier's state pruning compares their compound IDs (base | BPF_ADD_CONST flag) as a single idmap entry. However, it never cross-checks that the underlying base IDs (with the flag stripped) are consistent with existing mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries A->B (for R2) and A|flag->C|flag (for R3), without detecting that A->C conflicts with A->B. State pruning then incorrectly succeeds, allowing the verifier to accept a program state it should reject. The fix adds an additional check_ids() call on the base IDs (with BPF_ADD_CONST stripped) whenever the flag is set, ensuring that if A was already mapped to B, any ADD_CONST derivative must also derive from B. This is reachable by any process that can load BPF programs; on systems with unprivileged BPF enabled, this requires no special privileges.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 7.0 | 6.11 | 7.0.10 | 7d73c72cccac |
| mainline | 6.11 | 7.1 | 2f2ec8e7730e |
| 6.12 | 6.11 | 6.12.91 | 13c02881e49a |
| 6.18 | 6.11 | 6.18.33 | 691adf738817 |