Linux Kernel EUVD-2026-86965

Requires local ability to load eBPF programs into the kernel - in practice CAP_BPF or CAP_SYS_ADMIN, OR a system configured to permit unprivileged eBPF (kernel.unprivileged_bpf_disabled=0). The specific trigger is a crafted eBPF program that compares two pointers where one has a type lacking the PTR_MAYBE_NULL flag but can still be NULL at runtime (e.g. a PTR_TO_MEM from bpf_rdonly_cast compared to a map-value pointer), causing the verifier to wrongly strip null-checking and allow a NULL dereference. Limiting factors: exploitation is local only (no remote vector), gated by BPF load privileges, impact is confined to a kernel crash (availability) with no code execution or data disclosure in the base vector, and affected kernels are those containing the flawed check_cond_jmp_op() inference (introduced around 6.2 per EUVD). Hosts that disable unprivileged BPF substantially reduce the exposed attacker population.

This is a genuine but moderate-priority kernel robustness flaw, not an urgent fire. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5 MEDIUM) is internally consistent with the description: exploitation requires local access and some privilege (the ability to load an eBPF program), and the only impact is availability - a kernel NULL pointer dereference (CWE-476) causing a panic/crash. There is no confidentiality or integrity impact in the vector, which aligns with the described outcome of an uncaught NULL dereference rather than a controllable write primitive. The EPSS score is very low (0.16%, 4th percentile), and the CVE is NOT listed in CISA KEV, and no public exploit is referenced - all three signals agree that real-world mass exploitation is unlikely. The main nuance defenders must weigh is the privilege prerequisite: the real risk hinges almost entirely on whether unprivileged eBPF loading is permitted on the host. On hardened systems where eBPF requires CAP_BPF/CAP_SYS_ADMIN, PR:L is arguably generous and real exposure is minimal; on systems allowing unprivileged BPF, the attacker population is larger. Note the description's example references a verifier logic flaw where a NULL map-value pointer dereference is missed - this is a local DoS, consistent with A:H only. No signals conflict materially; all point to a low-to-moderate, privilege-gated local DoS.

A local user able to load eBPF programs submits a crafted program that compares a PTR_TO_MEM pointer (which can be NULL at runtime) against a PTR_TO_MAP_VALUE pointer, defeating the verifier's incorrect non-null inference in check_cond_jmp_op(). The verifier accepts the program, which then dereferences the NULL pointer, triggering a kernel panic and denial of service. No public exploit was identified at time of analysis; exploitation requires local access and eBPF load privileges.