Linux Kernel EUVD-2026-82235

Requires the ability to load eBPF programs into the kernel - i.e. CAP_BPF or CAP_SYS_ADMIN, or a system where the unprivileged BPF sysctl (kernel.unprivileged_bpf_disabled) is left enabled (disabled by default on most modern distributions, which is the primary limiting factor). The vulnerable code path requires a kernel new enough to support BPF_MEMSX sign-extending narrowing loads (~6.6+ / cpu=v4 instruction set). Exploitation needs a specifically crafted instruction sequence: spill a scalar to a stack slot, fill it with both a BPF_MEM (zero-extend) and a BPF_MEMSX (sign-extend, value-changing) load so the registers share a scalar id, then use an equality comparison to drive sync_linked_regs() into refining the sign-extended register. No network exposure and no user interaction; it is entirely local. Attack complexity is low because the verifier miscalculation is deterministic once the instruction pattern is constructed.

This is a genuine BPF verifier logic flaw (CVE-2026-93127) whose real-world risk depends almost entirely on who can load BPF programs. The vendor CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8 HIGH) is credible for this class: unlike many crash-only kernel bugs, the description explicitly states the miscalculation 'can be turned into an out-of-bounds access,' which is the textbook BPF local-privilege-escalation primitive (verifier believes 0x80000000 while the register actually holds 0xffffffff80000000, defeating bounds checking). I MOSTLY AGREE with the vendor here - a controllable verifier OOB read/write is a real memory-corruption primitive, so C:H/I:H/A:H is defensible when the attacker can reach it. The limiting factor is authentication/capability: BPF_MEMSX sign-extending loads are a modern verifier feature and loading programs requires CAP_BPF/CAP_SYS_ADMIN or the (default-off on modern distros) unprivileged-BPF sysctl, matching PR:L. No EPSS score, no CISA KEV listing, and no public exploit are present in the input - so this is not confirmed exploited. Signals are internally consistent (local vector, low complexity, low-but-nonzero privilege); the main caveat is that raw 7.8 overstates practical risk on hardened systems where unprivileged BPF is disabled, effectively raising the required privilege.

A local user with CAP_BPF (or on a system where unprivileged BPF is enabled) loads a crafted BPF program that spills a scalar to a stack slot, then fills the same slot twice - once with a plain zero-extending load (BPF_MEM) and once with a sign-extending narrowing load (BPF_MEMSX) - so both destination registers share one scalar id but hold different values. A subsequent 'if <zext-reg> == const' comparison causes the verifier's sync_linked_regs() to refine the sign-extended register to a value it never holds at runtime, letting the attacker bypass bounds checks and perform an out-of-bounds kernel access for privilege escalation. No public proof-of-concept is identified at time of analysis.