CVE-2026-46131

What it actually does

This flaw affects the Linux kernel KVM x86 virtualization subsystem. KVM incorrectly used a broad nested-guest check before translating a nested guest physical address during slow TLB-flush hypercall handling. That translation path is only valid when a second-level guest is running with nested EPT/NPT enabled. If a local attacker can run or control a KVM guest in a configuration that exposes nested virtualization behavior, they may be able to trigger an invalid kernel code path and cause a host-side kernel crash or severe availability failure. The impact is availability-only; there is no indication from the published details of confidentiality loss, integrity modification, or remote unauthenticated exploitation.

Why it matters to the business

Successful exploitation can disrupt Linux hosts that run KVM-based virtualization by crashing or destabilizing the host kernel, which may interrupt virtual machines and dependent services. The risk is most relevant to systems where untrusted or semi-trusted users can create, run, or administer KVM guests, including development, CI, hosting, lab, and cloud-like virtualization platforms. The CVSS score is medium, EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so remediation should be prioritized based on exposure to untrusted local users or nested virtualization rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first needs local privileges sufficient to interact with KVM, typically by running a virtual machine or controlling guest code on a host where KVM and nested virtualization features are available. The attacker then places the virtual CPU into a nested-guest-related state that satisfies KVM's general guest-mode check but does not have nested EPT/NPT enabled. From that state, the attacker triggers a slow TLB-flush hypercall path. Because the vulnerable kernel used the wrong condition before calling nested GPA translation logic, KVM may attempt a translation that is invalid for the current nested paging mode. The result can be a kernel fault, Oops, panic, or KVM host instability, causing denial of service to the host and its virtual machines.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the KVM x86 fix for this issue. Because no exact fixed versions were provided in the input, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch. Reboot into the patched kernel after installation; simply installing kernel packages is not sufficient if the host continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by disabling nested virtualization for untrusted guests, restricting access to /dev/kvm, limiting membership in groups that can run KVM workloads, isolating untrusted virtualization workloads onto patched hosts, and applying host-level monitoring for kernel crashes or repeated guest-triggered KVM faults.

How to confirm the fix worked

Confirm that the running kernel, not just the installed kernel package, is updated to a vendor build containing the KVM x86 nested EPT/NPT slow-flush hypercall fix. Validate with commands such as uname -a, package manager kernel inventory, and vendor advisory mapping for the active kernel version. Confirm that systems requiring mitigation have nested virtualization disabled or restricted, for example by reviewing KVM module parameters and virtualization platform settings. Exercise a controlled regression test using nested virtualization workloads if applicable, and verify there are no host kernel Oops, panic, or KVM fault messages during guest TLB-flush and nested virtualization activity. Also verify that /dev/kvm access is limited to intended administrators or service accounts.

Typical attack path

1. Obtain local access to a Linux system with KVM enabled, or gain control of code running in a guest where nested virtualization is exposed.
2. Ensure the ability to create, configure, or execute guest workloads that exercise nested x86 virtualization behavior.
3. Enter a nested-guest execution state without nested EPT/NPT enabled, or otherwise trigger the vulnerable mismatch between guest-mode state and nested paging capability.
4. Invoke or cause slow TLB-flush hypercall handling from the guest context.
5. Trigger the invalid nested GPA translation path in KVM.
6. Cause a host kernel Oops, panic, or KVM instability resulting in denial of service.

How to detect it

To determine whether this was already exploited, review host-side Linux kernel logs, hypervisor logs, virtualization management logs, and crash dumps from KVM hosts. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, libvirt logs, QEMU logs, and audit logs showing access to /dev/kvm. Look for kernel Oops, panic, BUG, general protection fault, NULL pointer dereference, or call traces involving KVM x86 nested virtualization, nested EPT/NPT, nested GPA translation, or TLB-flush hypercall handling. Correlate those events with guest lifecycle activity, nested virtualization enablement, unexpected VM starts, repeated VM crashes, and local users or service accounts opening /dev/kvm shortly before the host fault. There are no known public exploit-specific payload strings from the supplied information, so detection should focus on behavioral evidence of KVM-triggered host instability and forensic correlation with local KVM access.

• translate_nested_gpa
• nested EPT
• nested NPT
• nEPT
• nNPT
• KVM: x86
• kvm
• /dev/kvm
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• Call Trace:
• is_guest_mode
• KVM_HC_TLB_FLUSH
• TLB flush
• nested virtualization

What your security team should do

• Inventory Linux systems running KVM, prioritizing hosts that allow untrusted users, tenants, developers, CI jobs, or lab users to create or control virtual machines.
• Patch and reboot exposed KVM hosts to a vendor kernel release that includes the fix, with higher priority for hosts with nested virtualization enabled.
• Temporarily disable nested virtualization or remove it from untrusted guest profiles until patching is complete.
• Restrict /dev/kvm access and review membership in groups such as kvm, libvirt, qemu, or equivalent virtualization administration roles.
• Monitor kernel logs and hypervisor logs for KVM-related Oops, panic, nested virtualization faults, or repeated guest-triggered TLB-flush failures.
• Because EPSS is low, the issue is not in CISA KEV, and no mature public exploit is indicated, prioritize based on local virtualization exposure rather than broad perimeter urgency.
• After patching, confirm the active booted kernel is the patched version and that older vulnerable kernels are not selected by default at reboot.