Linux Kernel CVE-2026-46171

The vulnerable code path is only reachable on RISC-V architecture systems running the Linux kernel KVM hypervisor where the RISC-V V (vector) extension is supported by the physical hardware and exposed to KVM guests. Exploitation requires the attacker to have local access with at least low privileges sufficient to interact with the KVM subsystem, typically membership in the 'kvm' group or equivalent (PR:L per CVSS). The memory leak is triggered during vCPU creation when the second vector buffer allocation (host_context.vector.datap) fails, which requires a low-memory condition or forced allocation failure. Systems running x86, ARM, or any non-RISC-V architecture are entirely unaffected. Exploitation is further limited by the rarity of RISC-V KVM deployments in production environments.

CVSS 5.5 with AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H correctly reflects a local, low-complexity memory exhaustion issue requiring no user interaction. EPSS at 0.02% (4th percentile) corroborates minimal exploitation probability, consistent with the highly specific exploitation surface: only RISC-V hardware running Linux KVM with vector extension support is affected. No KEV listing and no identified POC further reduce urgency. The 'Information Disclosure' tag conflicts with CVSS C:N - confidentiality impact is not confirmed and should not be treated as an additional risk signal. The gap between the high CVSS A:H sub-score and the low EPSS is explained by the niche architecture (RISC-V KVM hypervisors remain rare in production), not by an inherent data conflict. This is a kernel stability and hardening fix with low operational urgency except for organizations running RISC-V KVM infrastructure.

A local attacker with low-privilege access on a RISC-V KVM host repeatedly initiates vCPU creation operations that trigger the vector context allocation path, engineering conditions where the second kzalloc fails (e.g., under memory pressure), causing guest_context.vector.datap to leak each cycle. Sustained iteration progressively exhausts kernel memory, degrading hypervisor stability and potentially causing a denial of service for hosted virtual machines. No POC has been identified, and the attack requires both RISC-V hardware and KVM vector support to be present.