CVE-2026-31413 is a Linux kernel eBPF verifier flaw in maybe_fork_scalars() affecting handling of ALU operations when the source operand is a constant. The function is used for both BPF_AND and BPF_OR. When the destination register has a signed range of [-1, 0], the verifier forks state such that the pushed path assumes dst = 0 and the current path assumes dst = -1. This behavior is sound for BPF_AND because 0 & K == 0, but unsound for BPF_OR because 0 | K == K rather than 0. As a result, for BPF_OR with a constant source, the pushed verifier path can incorrectly track dst as 0 while the runtime value is actually K. This creates a verifier/runtime state divergence. The upstream fix changes push_stack() to use env->insn_idx instead of env->insn_idx + 1 so the forked path re-executes the ALU instruction with dst = 0 and derives the correct post-operation value for the opcode.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Repository is a standalone Linux kernel eBPF exploit research repo for CVE-2026-31413, a verifier soundness bug in maybe_fork_scalars() affecting BPF_OR handling. It contains a progression from validation PoCs to full privilege-escalation/container-escape exploits. The core bug is a verifier/runtime divergence: the verifier tracks a forked register as 0 while runtime computes 0|K=K, allowing crafted BPF socket-filter programs to pass bounds checks and perform out-of-bounds accesses on BPF map values. Structure: bpf_helpers.h provides raw BPF instruction macros, syscall wrappers, verifier log helpers, and a socketpair-based trigger path. The poc/ directory contains staged research artifacts: validate_bug.c and exploit_or_fork*.c prove the bug and demonstrate OOB reads/writes; leak_map_addr.c and step1_leak_ops.c leak kernel pointers from bpf_map metadata; step2_oob_rw.c turns the bug into negative-offset OOB read/write; step3_arb_read.c abuses a corrupted btf pointer plus BPF_OBJ_GET_INFO_BY_FD for arbitrary kernel reads; test_oob.c contains broader verifier/OOB experiments. The exploit/ directory contains full exploit chains: exploit.c is a host-root exploit with hardcoded kernel addresses (KASLR off), exploit_ctf.c adapts for kernelCTF by deriving KASLR slide and reading /flag, and exploit_gke.c targets container escape/GKE-style environments by resolving symbols from /proc/kallsyms and using host namespace paths. Additional exploit_or_fork*.c files are intermediate exploit-development variants. The demo/ directory includes a Dockerfile and demo_escape.sh to reproduce a container escape scenario. patches/ contains the upstream fix and selftests. Main exploit capability: create arbitrary kernel read/write by corrupting BPF map metadata and hijacking bpf_map_ops, then overwrite modprobe_path to execute attacker-controlled shell scripts as root. The final result is host root, SUID shell drop, sensitive file access, and container escape. This is clearly exploit code rather than mere detection, though several files are PoCs and validation utilities supporting the final chain.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
7 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.