HIGH Introduced in 5.10
bpf Verifier FailPath Bypass
CVE-2026-53090
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.7HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.
02KernelScan AI Analysis
Risk summary
A local user with BPF program loading privileges can craft a BPF subprogram using ld_abs or ld_ind instructions whose abnormal exit path is not verified by the kernel verifier. This allows the attacker to bypass verifier safety checks, potentially leading to arbitrary kernel memory read/write and privilege escalation. Systems where unprivileged BPF is enabled are at higher risk.
Vulnerability analysis
The BPF verifier failed to simulate the abnormal exit path of ld_abs/ld_ind instructions when used inside BPF subprograms. The code generator bpf_gen_ld_abs() emits a hidden BPF_EXIT with r0=0 when a packet data load fails, but the verifier only analyzed the success path (r0=unknown, continue to next instruction). This means the verifier never validated the state of registers and stack on the failure path, allowing a crafted BPF program to pass verification with an unverified code path that executes at runtime. The fix adds explicit simulation of both paths: the success path (r0=unknown) is pushed onto the verifier stack for later validation, while the failure path (r0=0, return to caller) is analyzed inline via prepare_func_exit(). Additionally, the visit_tailcall_insn() function is generalized into visit_abnormal_return_insn() to handle both tail calls and ld_abs/ld_ind instructions in the CFG traversal. The attack surface requires loading a BPF program, which on most systems requires CAP_BPF or CAP_NET_ADMIN, reachable by low-privileged users on systems with unprivileged BPF enabled.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 5.10 | 6.18.42 | ce01a4e5cfac |
| 7.0 | 5.10 | 7.0.10 | d846d83bdacb |
| 6.6 | 5.10 | 6.6.148 | 37ad2bb11e9d |
| 6.12 | 5.10 | 6.12.101 | 8674e2db06cf |
| 5.15 | 5.10 | 5.15.216 | 8a800497d9f6 |
| 5.10 | 5.10 | 5.10.265 | 928d354ae355 |
| 6.1 | 5.10 | 6.1.183 | de1055e7f9e6 |
| mainline | 5.10 | 7.1 | ee861486e377 |