CVE-2026-46059

What it actually does

This is a Linux kernel KVM vulnerability in AMD SVM nested virtualization handling. When an L1 guest runs an L2 guest with NRIPS disabled and injects a software interrupt, KVM can use the wrong instruction pointer value after the first nested VMRUN, especially across save/restore-style state transitions. The result is incorrect nested guest control block state and potentially fatal KVM or host-kernel behavior. The practical security impact is local, low-privilege denial of service: an attacker who can execute code in a VM with access to nested virtualization can crash or destabilize the host kernel or virtualization stack. There is no indication from the provided data that this enables confidentiality loss, privilege escalation, or remote code execution.

Why it matters to the business

Organizations running Linux KVM on AMD hardware with nested virtualization enabled may face unplanned outages if an untrusted or compromised virtual machine intentionally triggers the flaw. The most likely business impact is disruption of virtualized workloads, host reboots, failed VM migrations or restores, and degraded service availability. The CVSS availability impact is high, but exploitation requires local access and a nested virtualization configuration, and the EPSS score is very low with no known KEV listing or mature public exploit reported, so urgency should be highest for multi-tenant, cloud, CI/CD, sandbox, or lab environments that expose nested virtualization to users.

How an attack unfolds

An attacker first needs code execution in a guest environment that can use KVM nested virtualization on an AMD SVM-capable Linux host. The attacker configures or runs an L1 hypervisor and launches a crafted L2 guest with conditions that disable NRIPS behavior. The L1 then injects a software interrupt into the L2 guest and drives execution through a nested VMRUN sequence. After the L2 has run once, the CPU or KVM updates NextRIP state, but vulnerable kernels can still derive vmcb02 state from the current RIP in cases where NextRIP should be used. By forcing save/restore or equivalent nested-state transitions, the attacker can cause KVM to resume the nested guest with inconsistent instruction-pointer state. This may trigger kernel faults, KVM assertion failures, VM instability, or a host-level crash, producing a denial-of-service condition for the affected virtualization host and its workloads.

How to fix it

Apply the Linux kernel update provided by the operating system or kernel vendor that includes the KVM nSVM fix for this issue. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories for the deployed distribution and kernel stream. Where immediate patching is not possible, reduce exposure by disabling nested virtualization for AMD KVM hosts, especially in multi-tenant or untrusted workload environments. This is commonly controlled by the kvm_amd nested parameter; confirm the vendor-supported method before changing production systems. Also restrict access to /dev/kvm, avoid granting nested virtualization to untrusted users or tenants, and consider migrating high-risk nested workloads to patched hosts.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version for the affected distribution, not merely that an updated package is installed on disk. Reboot if required so the patched kernel is active. Validate exposure by checking whether the kvm_amd module is loaded and whether nested virtualization is enabled, for example by reviewing /sys/module/kvm_amd/parameters/nested where present. Confirm that untrusted users or workloads cannot access /dev/kvm unless nested virtualization is explicitly required. For functional validation, run vendor or upstream KVM nested virtualization regression tests on patched hosts and verify there are no kernel oops, panic, or KVM nSVM errors during nested guest save/restore and soft-interrupt scenarios.

Typical attack path

1. Obtain local code execution inside a VM or environment allowed to use nested virtualization.
2. Confirm the host exposes AMD SVM/KVM nested virtualization to the guest.
3. Run an L1 hypervisor inside the guest and create a crafted L2 guest workload.
4. Configure execution so NRIPS is disabled or emulated behavior is used.
5. Inject a software interrupt into the L2 guest and execute the first nested VMRUN.
6. Trigger nested state save/restore or resume behavior after L2 has already executed.
7. Cause KVM to use incorrect RIP/NextRIP state in vmcb02.
8. Crash or destabilize the host kernel or KVM virtualization stack, resulting in denial of service.

How to detect it

Detecting prior exploitation is difficult because the triggering activity occurs inside nested virtualization and may leave only host-side crash evidence. Review host kernel logs, persistent journal records, hypervisor logs, crash dumps, and monitoring data for unexpected reboots, kernel panics, KVM nSVM faults, or VM failures correlated with guests that use nested virtualization. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, systemd journal persistent storage, kdump/vmcore artifacts, libvirt logs, QEMU process logs, and hypervisor orchestration audit logs. Look for a pattern of host instability immediately after nested guest execution, VM save/restore, migration, or resume operations. If guest telemetry is available, look for users running hypervisors inside VMs shortly before a host crash. Because no public exploit indicators, malware names, file paths, network signatures, or actor-specific artifacts were provided, detection should focus on behavioral correlation rather than static IOCs.

• kvm_amd
• /sys/module/kvm_amd/parameters/nested
• /dev/kvm
• KVM: nSVM
• nested virtualization
• kernel panic
• BUG: unable to handle kernel
• Oops:
• vmcore
• qemu-system-x86_64

What your security team should do

• Prioritize patching AMD-based Linux KVM hosts that allow nested virtualization, especially multi-tenant, CI/CD, sandbox, hosting, or developer platforms.
• Temporarily disable nested virtualization on vulnerable hosts where it is not business-critical.
• Restrict /dev/kvm access to trusted virtualization processes and administrators only.
• Inventory hosts with kvm_amd loaded and nested virtualization enabled to determine exposure scope.
• Review recent host crashes, kernel panics, unexplained reboots, and KVM errors for possible exploitation or testing activity.
• Coordinate maintenance windows for kernel updates and required reboots because remediation may not take effect until the fixed kernel is running.
• Monitor vendor advisories for exact fixed kernel package versions and backports for each deployed Linux distribution.
• Do not treat this as remotely exploitable from the network without local guest access and nested virtualization exposure, but do treat it as a serious availability risk on shared virtualization infrastructure.