CVE-2026-53670: PREVAIL eBPF Verifier Use-After-Free

CVE-2026-53670 Overview

CVE-2026-53670 affects PREVAIL, a Polynomial-Runtime eBPF Verifier that uses an Abstract Interpretation Layer to statically validate BPF programs. Versions prior to 0.2.4 contain an incorrect calculation flaw [CWE-682] in EbpfTransformer::add(). The function silently skips offset-variable updates when the destination register carries a non-singleton typeset representing two or more simultaneously possible pointer types. Later bounds checks then reason from a stale pre-arithmetic offset and accept out-of-bounds memory accesses. A crafted BPF program passes verification while corrupting memory at runtime.

Critical Impact
A crafted eBPF program can bypass verifier bounds checks and perform out-of-bounds memory access at runtime, breaking the core memory-safety guarantee that PREVAIL is designed to enforce.

Affected Products

PREVAIL eBPF verifier versions prior to 0.2.4
Downstream projects embedding the vbpf/prevail library for BPF program verification
Hosts and runtimes that rely on PREVAIL to gate BPF program loading

Discovery Timeline

2026-09-02 - CVE-2026-53670 published to NVD
2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-53670

Vulnerability Analysis

PREVAIL performs abstract interpretation over BPF programs to prove memory safety before the kernel loads them. Each register carries a typeset describing the pointer or numeric domains it may hold. When EbpfTransformer::add() processes an add or subtract on a register whose typeset spans multiple pointer kinds, the transformer previously failed to advance any offset variable. Subsequent path-sensitive bounds checks then compared access ranges against the pre-arithmetic offset. An attacker who constructs a program that briefly unifies two pointer types in one register can hide arbitrary offset growth from the analyzer.

Root Cause

The defect is a missing invariant update in the abstract domain. When the destination register may still be numeric, the numeric addition path advances integer values but never invalidates pointer offsets. When no single primary kind variable can be selected because the typeset is non-singleton, the fallback path never widens or havocs the offset variables. Both cases leave stale symbolic offsets that later verification steps treat as authoritative, violating the soundness contract of the abstract interpretation layer.

Attack Vector

Exploitation requires the ability to submit a BPF program to a host that uses PREVAIL for verification. The attacker crafts instruction sequences that force a register into a union type such as {number, pointer} or two distinct pointer kinds, then performs arithmetic on that register. The verifier accepts the resulting out-of-bounds load or store, and the kernel or user-space BPF runtime executes it, corrupting memory outside the intended map or stack region.

cpp

     const auto dst = reg_pack(dst_reg);
     if (dom.state.may_have_type(dst_reg, T_NUM)) {
         dom.state.values->add_overflow(dst.svalue, dst.uvalue, imm, finite_width);
+        if (!dom.state.is_in_group(dst_reg, TS_NUM)) {
+            // The destination may also be a pointer (a {number, pointer} union). The numeric
+            // path above does not advance any pointer offset, so invalidate them rather than
+            // leaving a stale offset that a later bounds check would reason from.
+            dom.state.havoc_offsets(dst_reg);
+        }
     } else {
         if (const auto kind = dom.state.primary_kind_variable_for_type(dst_reg)) {
             dom.state.values->add(*kind, imm);
+        } else {
+            // The register's typeset is non-singleton, so we cannot pick a single offset
+            // variable to update. Conservatively invalidate all offset variables rather than
+            // leaving them stale, which would make subsequent bounds checks use a pre-add
+            // offset and accept out-of-bounds accesses. Mirrors shl()/lshr()/ashr().
+            dom.state.havoc_offsets(dst_reg);
         }
         dom.state.values->apply_unsigned(ArithBinOp::ADD, dst.svalue, dst.uvalue, dst.uvalue, imm, finite_width);
     }

Source: PREVAIL patch commit 2b209bc4. The patch calls havoc_offsets(dst_reg) on both non-singleton paths, matching how shl(), lshr(), and ashr() already handle the same class of ambiguity.

Detection Methods for CVE-2026-53670

Indicators of Compromise

BPF programs that pass PREVAIL verification yet trigger runtime memory faults, kernel oops entries, or KASAN reports on load or execution.
Unexpected reads or writes outside declared BPF map bounds observed via kernel tracepoints or bpf_trace_printk output.
Presence of PREVAIL library versions earlier than 0.2.4 in build manifests, container images, or SBOMs.

Detection Strategies

Audit dependency graphs and package lockfiles for vbpf/prevail versions below 0.2.4 across build pipelines and container registries.
Compare verification decisions between the patched PREVAIL 0.2.4 and any older cached verifier to identify programs that previously verified but now fail.
Review submitted BPF bytecode for arithmetic on registers whose static analysis shows non-singleton pointer typesets.

Monitoring Recommendations

Log every BPF program load event with SHA-256 hashes, submitting user, and verifier version.
Alert on kernel messages indicating BPF runtime bounds violations, page faults inside BPF programs, or map access anomalies.
Track PREVAIL library upgrades across fleet hosts to confirm consistent adoption of version 0.2.4.

How to Mitigate CVE-2026-53670

Immediate Actions Required

Upgrade all deployments of the PREVAIL verifier to version 0.2.4 or later.
Rebuild and redeploy any downstream tools, agents, or services that statically link or vendor the vbpf/prevail library.
Restrict BPF program submission to trusted principals until the upgraded verifier is in place.

Patch Information

The fix is available in PREVAIL release v0.2.4 and detailed in GitHub Security Advisory GHSA-2qc8-qh94-66rc. The corrective change in src/crab/ebpf_transformer.cpp invalidates all offset variables when the destination register carries a non-singleton typeset, preventing subsequent bounds checks from reasoning against stale offsets.

Workarounds

Disable acceptance of untrusted BPF programs on hosts that cannot immediately upgrade PREVAIL.
Require an additional verifier pass, such as the in-kernel BPF verifier with strict settings, alongside PREVAIL until the patched version is deployed.
Enforce code signing or allowlisting of BPF program hashes to reduce exposure to attacker-supplied bytecode.

bash

# Verify the installed PREVAIL version and upgrade if below 0.2.4
git -C prevail describe --tags
git -C prevail fetch --tags
git -C prevail checkout v0.2.4
cmake -S prevail -B prevail/build && cmake --build prevail/build