Linux kernel BPF verifier: ld_abs/ld_ind failure path left unverified inside subprograms

Impact

bpf_gen_ld_abs() emits an abnormal exit path (r0=0, return to caller) when the packet load fails, and the verifier never simulated it for subprogram uses. A program can therefore be accepted with a reachable path whose register state was never checked - the classic shape behind verifier-based local privilege escalation, and NVD scores it accordingly at 7.8 with full C/I/A. On a GPU fleet the loaders of BPF are usually privileged infrastructure (CNI dataplanes, tracing and security agents), so the practical exposure is workloads or sidecars that have been granted CAP_BPF, plus any host where unprivileged BPF is still permitted. It is not reachable from a plain tenant pod on a default modern distro configuration.

Who can reach it

Local user able to load a BPF program with ld_abs/ld_ind in a BTF-annotated subprogram - CAP_BPF (or CAP_SYS_ADMIN), or any local user on a host where kernel.unprivileged_bpf_disabled is 0.

What to do

Update to a stable kernel with the verifier fix and reboot the node. Until then, confirm kernel.unprivileged_bpf_disabled is set and audit which pods hold CAP_BPF - that bounds who can reach the verifier at all. Rolling reboots on GPU nodes require draining jobs, so pair this with other pending kernel fixes rather than opening a window for it alone.

References