CVE-2026-46171

What it actually does

This is a local availability vulnerability in the Linux kernel's RISC-V KVM virtualization code. During allocation of vector context memory for a virtual CPU, if allocation of the host vector data buffer fails after the guest vector data buffer has already been allocated, the guest allocation is not freed before the function returns. A local user or process with the ability to create or manipulate KVM virtual CPUs on an affected RISC-V system can repeatedly trigger this failure path, causing kernel memory to leak and potentially leading to memory exhaustion, degraded host performance, or denial of service. There is no known confidentiality or integrity impact from the flaw itself.

Why it matters to the business

Organizations running KVM virtualization on affected RISC-V Linux systems could experience host instability or outages if local users, tenants, build jobs, test harnesses, or compromised workloads can repeatedly create KVM vCPUs and force allocation failures. The most likely consequence is service disruption from memory exhaustion rather than data theft. The risk is lower for systems that do not use RISC-V, do not enable KVM, or do not allow untrusted users access to KVM. The CVSS score is moderate and EPSS is very low, with no known KEV listing or public exploit maturity reported, but virtualization hosts should still be patched because local denial-of-service flaws can affect many workloads at once.

How an attack unfolds

An attacker first needs local code execution on an affected RISC-V Linux host and sufficient access to the KVM interface, typically through membership in a group that can open /dev/kvm or through a service that creates virtual machines on the attacker's behalf. The attacker then repeatedly attempts to create KVM virtual CPUs with RISC-V vector context enabled or otherwise reaches the vector context allocation path. By creating memory pressure so that the second allocation fails after the first allocation succeeds, the vulnerable kernel path returns without freeing the first buffer. Repeating this sequence leaks kernel memory over time. If performed at sufficient scale, the host can suffer reduced available memory, OOM-killer activity, failed VM creation, degraded performance, or a host-level denial of service. No remote network-only exploitation path is indicated by the vulnerability metadata.

How to fix it

Upgrade the Linux kernel to a version or vendor package that includes the upstream fix for the RISC-V KVM vector context allocation leak. No exact fixed package versions were provided in the input, so use the relevant distribution, appliance, cloud image, or kernel vendor advisory to identify the corrected kernel build. After upgrading, reboot into the patched kernel and confirm the running kernel version, not only the installed package version. As interim mitigations, restrict access to /dev/kvm to trusted administrators and virtualization services, disable or avoid KVM on affected RISC-V systems where it is not required, limit untrusted VM/vCPU creation, enforce per-user process and memory limits, and monitor for abnormal VM creation failures or host memory pressure.

How to confirm the fix worked

Confirm whether the system is both RISC-V and using KVM; non-RISC-V systems or systems without KVM exposure are not expected to be affected by this specific code path. Validate remediation by checking that the running kernel is a vendor-fixed build containing the patch that frees guest_context.vector.datap when host_context.vector.datap allocation fails in kvm_riscv_vcpu_alloc_vector_context. Confirm the host was rebooted into the patched kernel using uname or equivalent fleet inventory. Review /dev/kvm permissions and group membership to verify only trusted users and services can access KVM. In test environments, repeated failed vCPU creation under controlled memory pressure should no longer produce steadily increasing unreclaimed kernel memory attributable to the RISC-V KVM vector context path.

Typical attack path

1. Gain local execution on an affected RISC-V Linux system or access to a service that can create KVM virtual machines or vCPUs.
2. Obtain permission to use the KVM device, commonly access to /dev/kvm through local privileges or an authorized virtualization workflow.
3. Create or manipulate KVM virtual CPUs in a way that invokes the RISC-V vector context allocation path.
4. Induce memory pressure so the first vector context allocation succeeds but the second allocation fails.
5. Repeat the operation to leak kernel memory across failed allocation attempts.
6. Cause host memory exhaustion, OOM-killer activity, VM failures, degraded service, or denial of service.

How to detect it

Detection should focus on signs of attempted local denial of service rather than a unique exploit signature. Review kernel logs, system logs, virtualization service logs, audit logs for /dev/kvm access, and resource monitoring data. Look for repeated VM or vCPU creation attempts followed by allocation failures, increasing unreclaimed kernel memory, OOM-killer activity, QEMU or KVM process failures, and service disruption on RISC-V virtualization hosts. Correlate suspicious activity with local users or processes opening /dev/kvm, especially if the activity comes from accounts that do not normally create virtual machines. Because the vulnerability is a memory leak on an error path, successful exploitation may leave only indirect artifacts such as memory pressure, allocation failure messages, killed processes, and repeated virtualization initialization failures. There are no public threat actors, ransomware campaigns, or KEV exploitation reports provided for this vulnerability.

• /dev/kvm
• qemu-system-riscv64
• kvm_riscv_vcpu_alloc_vector_context
• host_context.vector.datap
• guest_context.vector.datap
• Out of memory
• invoked oom-killer
• oom-kill
• page allocation failure
• kzalloc
• Cannot allocate memory
• failed to allocate
• KVM
• riscv: kvm

What your security team should do

• Prioritize patching RISC-V Linux systems that run KVM virtualization or expose /dev/kvm to non-administrative users, CI jobs, tenants, or automation.
• Inventory RISC-V hosts separately from general Linux fleets, because this vulnerability is architecture-specific and may be missed by generic kernel checks.
• Verify that patched kernel packages are not only installed but actively running after reboot.
• Restrict /dev/kvm access to trusted users and service accounts; remove unnecessary users from KVM-related groups.
• Apply resource controls to untrusted local workloads, including process, memory, and VM creation limits where supported.
• Monitor affected hosts for unexplained memory pressure, OOM-killer events, repeated KVM or QEMU failures, and spikes in vCPU or VM creation attempts.
• Treat suspicious exploitation as a local post-compromise activity and investigate how the user or process obtained KVM access.
• Track vendor advisories for exact fixed kernel versions if using distribution kernels, embedded RISC-V platforms, or appliance-maintained kernels.