PREVAIL: writes through a context pointer are modelled as a no-op, so unsafe eBPF programs verify as safe

Impact

PREVAIL is the eBPF verifier used where the in-kernel Linux verifier is not (notably eBPF-for-Windows and embedded verification harnesses). Before 0.2.4, do_mem_store in the abstract transformer only models T_STACK stores and the checker's T_CTX bounds arm never tests AccessType::write, so a store through a context-typed base register is treated as having no effect. A program can overwrite a context field such as ctx->data, reload it typed as T_PACKET, and dereference an address of the attacker's choosing - and PREVAIL still reports the program safe. Anywhere PREVAIL is the gate that lets a less-trusted party load a program, that gate does not hold; the consequence is memory read and write at the privilege of whatever runs the program. On a GPU node this matters only where such a load path is exposed to tenants, which is uncommon but is exactly the case in observability and network-policy stacks that verify submitted programs.

Who can reach it

Anyone who can submit an eBPF program to a component that relies on PREVAIL for verification. The record describes this as reachable without authentication in that submission path; it is not a remote pre-auth bug against a normal server.

What to do

Upgrade PREVAIL to 0.2.4 (commit de65234) and rebuild and restart anything that links it. Until then, do not accept eBPF programs from untrusted submitters on PREVAIL-gated paths. Note this is a distinct flaw from CVE-2026-53706 in the same release - both are fixed by the same version bump but they are separate defects with separate commits.

References

Related entries

• Linux kernel (arch/x86/kvm/svm): Page State Change requests from a confidential guest were validated against theCVE-2026-63938 · Linux kernel (arch/x86/kvm/svm)Critical
• Linux kernel (arch/x86/kvm/svm): KVM computed the usable size of the guest-provided GHCB scratch area wrongly, so aCVE-2026-63939 · Linux kernel (arch/x86/kvm/svm)Critical
• Linux kernel (arch/x86/kvm/svm): A confidential guest can hand KVM a port-I/O request with length or count zeroCVE-2026-63940 · Linux kernel (arch/x86/kvm/svm)Critical
• Linux kernel arm_ffa: use-after-free racing a notifier unregister against notification deliveryCVE-2026-64080 · Linux kernel arm_ffa firmware driver (notification callback lookup)Critical
• Linux kernel (drivers/iommu/intel): The VT-d scalable-mode context entry is zeroed while its Present bit is still setCVE-2026-74439 · Linux kernel (drivers/iommu/intel)Critical
• Linux kernel (arch/x86/kvm): The I/O APIC's delayed EOI work was cancelled only after vCPUs were freed, so the workCVE-2026-74517 · Linux kernel (arch/x86/kvm)Critical