PREVAIL eBPF Verifier CVE-2026-53706

Exploitation requires that the target system uses prevail as its eBPF verifier and that the attacker can submit eBPF programs for verification. The advisory explicitly confirms that unprivileged users on kernels permitting BPF program loading fall within scope, meaning no authentication is required under those configurations, consistent with PR:N in the provided CVSS 4.0 vector. The vulnerable instruction pattern is specifically ALU32 ADD (w-prefix notation, e.g., w1 += w2) or ALU32 SUB (w1 -= w2) targeting a destination register of pointer type (ctx, stack, packet, or shared). No special runtime configuration beyond access to the BPF program submission interface is required. Exploitation is limited to environments deploying prevail as the verification layer - systems relying solely on the Linux kernel's native eBPF verifier are not affected.

The CVSS 4.0 score of 8.8 with AV:N/AC:L/PR:N reflects that prevail is commonly invoked for user-submitted programs, including from unprivileged callers, making the verifier surface broadly reachable. Real-world exploitation is bounded by the requirement that the target environment specifically uses prevail for eBPF verification and permits program submission from untrusted callers; environments running only the Linux kernel's native verifier are entirely unaffected. EPSS data is absent from the provided intelligence, and the CVE is not listed in CISA KEV, indicating no confirmed active exploitation. The dual-impact nature - runtime faults (VA:H) and potential partial kernel address disclosure (the lower 32 pointer bits leakable as a scalar, noted explicitly in fix commit comments) - means risk extends beyond a simple crash scenario, and any team deploying eBPF for Windows should treat this as an urgent patch given the verifier's role as the primary safety gate. The VC:N rating in the provided CVSS 4.0 vector may marginally understate the kernel address leakage risk documented in the fix's inline code, though the exposure is limited to the lower 32 bits of a pointer rather than a full address disclosure.

An unprivileged user submits a crafted eBPF program containing an ALU32 ADD instruction (w1 += w2) where r1 holds a context pointer; prevail fails to check the register's pointer type before masking, so the program is incorrectly marked as verified safe. At runtime the zero-extended truncated value is used as the base for a memory load, which either faults and crashes the program or returns the lower 32 bits of a kernel context address as a scalar, partially exposing kernel address space layout. The regression tests added in the fix commit provide a near-complete reproduction blueprint, though no standalone public PoC has been identified.