CVE-2026-46131

Technical summary

The vulnerability lies in the KVM x86 hypervisor's TLB flush hypercall handling. The vulnerable code path uses is_guest_mode(vcpu) to determine whether translate_nested_gpa() can be safely called, but this function is only valid when nested EPT/NPT is active. When a nested guest issues certain hypercalls without nested paging enabled, the hypervisor attempts to dereference invalid memory translation structures, leading to a null pointer dereference or memory access violation. The fix aligns the hypercall validation with the actual preconditions required by translate_nested_gpa()—specifically, checking that both nested virtualization is active *and* hardware-assisted paging is enabled.

Business impact

Organizations running nested virtualization workloads on Linux KVM hosts face availability risk. A guest user with local access can crash or hang a nested virtual machine by invoking slow TLB flush hypercalls, disrupting service continuity. Multi-tenant environments where customers run nested guests are at greater risk. Data confidentiality and integrity are not affected. The impact is isolated to individual nested guest availability, not the host or sibling guests.

Affected systems

The Linux kernel is affected across versions that include the vulnerable KVM code path. This impacts any hypervisor platform built on Linux KVM that supports nested virtualization, including KVM itself, OpenStack deployments using KVM, and other nested virtualization stacks. Systems not using nested virtualization (non-nested guests only) are not affected. Verify your specific kernel version against the patch timeline provided by Linux distribution vendors.

Exploitability

Exploitability requires local access—an attacker must be able to execute code or issue hypercalls from within a nested guest VM. This is not a privilege escalation; normal guest users can trigger the vulnerability. No special configuration or user interaction is needed beyond running malicious code inside a nested guest. The barrier to exploitation is the ability to run arbitrary code in a guest, which is within the threat model of nested virtualization. The vulnerability is not remotely exploitable from the host or other guests.

Remediation

Apply kernel patches that add proper nEPT/nNPT validation before calling translate_nested_gpa() in slow flush hypercall handlers. The fix involves replacing the is_guest_mode() check with a more precise condition that verifies both nested virtualization mode and the availability of nested paging hardware support. Patch availability and version numbers vary by Linux distribution; check your vendor's security advisory for backported fixes to your kernel series.

Patch guidance

Obtain patches from your Linux distribution's security team (Red Hat, Ubuntu, Debian, SUSE, etc.) rather than directly from the upstream Linux kernel, as they typically backport fixes to supported kernel versions with higher priority. The fix is conceptually straightforward but must be integrated carefully into your kernel version series. After patching, no host or guest configuration changes are required; reboot to apply the kernel update. Test in a non-production nested virtualization environment first to ensure compatibility with your workloads.

Detection guidance

Monitor nested guest crash or hang events correlated with TLB-related hypercall activity. In kernel logs, look for warnings or panics involving translate_nested_gpa() or nested paging faults occurring during slow flush operations. If you have detailed KVM tracing enabled, examine hypercall exits for patterns where slow flush (vmexit code ~0x18) is followed by guest instability. Check your hypervisor's metrics for unexpected nested guest resets or high VM exit rates on affected hosts. Behavioral detection is difficult; the best indicator is kernel logs showing memory access violations in the KVM EPT/NPT path during nested guest operation.

Why prioritize this

This vulnerability merits medium priority attention because it requires local guest access but causes immediate denial of service to affected nested guests. Organizations operating nested virtualization in multi-tenant or public cloud scenarios should prioritize patching to prevent guest-initiated DoS. However, if you do not use nested virtualization, the risk is minimal and can be scheduled with routine kernel updates. The fix is low-risk and is unlikely to introduce regressions in non-nested virtualization scenarios.

Risk score, explained

The CVSS 3.1 score of 5.5 (Medium, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects: local attack vector (requires guest access), low complexity (no special conditions beyond nested mode), low privileges required (guest user level), no user interaction, scope unchanged (only the nested guest), zero confidentiality impact, zero integrity impact, and high availability impact (guest DoS). The score appropriately captures the real-world threat: a straightforward but contained local denial of service within the nested guest boundary, with no lateral or escalation potential.

Frequently asked questions