Linux Kernel EUVD-2026-82220

Requires a kernel version 6.15 through the fixed releases with BPF and the sched_ext (scx) infrastructure available, plus a local actor able to load and run BPF programs (CAP_BPF / effectively CAP_SYS_ADMIN). The specific trigger is a BPF program that calls bpf_cpumask_populate() with a destination pointer obtained from a read-only query kfunc such as scx_bpf_get_online_cpumask() - i.e., a borrowed const cpumask rather than a program-owned bpf_cpumask. Limiting factors: no remote vector (AV:L), no unauthenticated path (BPF-load privilege needed), unaffected on kernels without sched_ext/cpumask kfuncs or where unprivileged BPF is disabled, and no user interaction is involved.

This is a genuine but low-urgency, hard-to-reach local privilege-context flaw, not a widespread emergency. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, 7.1) correctly places it as local with some privilege required and no confidentiality impact - consistent with a BPF type-confusion that requires the ability to load and run BPF programs (effectively CAP_BPF/CAP_SYS_ADMIN). There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so all exploitation-probability signals point to zero real-world activity. The vendor rates I:H/A:H, but the actual primitive is a bounded bitmap_copy() write into a borrowed (read-only) cpumask the program does not own - a corruption/DoS-primary bug rather than a full integrity-takeover, so I assess impact closer to C:N/I:L/A:H (~5.0-5.5). Note a metadata conflict: the 'Information Disclosure' tag contradicts the vendor's own C:N (no confidentiality impact) - this is a write/corruption issue, so that tag is mislabeled. Net: real code defect, patched, but niche reachability and no exploitation signals make it a routine kernel-update priority, not a drop-everything item.

A local user with BPF load privileges (CAP_BPF) on a kernel built with sched_ext writes a BPF program that obtains a borrowed, read-only cpumask from a query kfunc such as scx_bpf_get_online_cpumask() and passes it as the destination to bpf_cpumask_populate(). Because the verifier accepted the wrong destination type, the bitmap_copy() writes over kernel-owned cpumask state the program should not be able to mutate, corrupting scheduling/online-CPU state and crashing or destabilizing the host. No public proof-of-concept exists at time of analysis.