CVE-2026-43133

What it actually does

This is a Linux kernel KVM vulnerability in AMD SVM nested virtualization handling. When an L2 nested guest executes VMLOAD or VMSAVE and the L1 hypervisor does not intercept it, KVM may incorrectly operate on vmcb02, the merged nested-guest control block, instead of vmcb01, the L1 guest control block. That can corrupt or expose virtualization state across nested virtualization boundaries and may allow a low-privileged local actor with access to a nested guest path to affect confidentiality, integrity, or, most significantly, host availability. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, changed scope, and high availability impact.

Why it matters to the business

Organizations running Linux KVM hosts with AMD nested virtualization enabled are most exposed, especially where untrusted or semi-trusted workloads can run their own nested hypervisors. Successful exploitation could crash or destabilize virtualization hosts, disrupt workloads, and potentially weaken isolation between nested virtualization layers. The current EPSS score is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad opportunistic exploitation is not indicated; however, because the issue is kernel-level and has been public for 98 days, delayed patching increases operational risk in virtualization platforms.

How an attack unfolds

An attacker first obtains low-privileged execution in an environment that can exercise KVM nested virtualization on an affected Linux kernel, typically involving an AMD SVM-capable host with nested virtualization enabled. The attacker arranges for an L2 guest to execute VMLOAD or VMSAVE while ensuring the L1 hypervisor does not intercept those instructions. Due to the kernel bug, KVM uses the wrong virtual machine control block for the emulation path. This mishandling can cause incorrect guest-state save/load behavior, leading to corruption of virtualization state and potentially a host kernel fault or isolation impact. There is no reported public exploit, so exploitation details should be treated as currently theoretical or limited to controlled research conditions unless local telemetry indicates otherwise.

How to fix it

Apply the Linux kernel update from the relevant operating system or kernel vendor that includes the KVM nSVM fix to always use vmcb01 for VMLOAD/VMSAVE emulation. No exact fixed package versions were provided in the input, so validate against vendor advisories and distribution changelogs for this CVE or the KVM nSVM VMLOAD/VMSAVE vmcb01 fix. Where immediate patching is not possible, reduce exposure by disabling nested virtualization for AMD KVM when it is not required, commonly by setting the kvm_amd nested parameter to 0 and reloading the module or rebooting according to distribution guidance. Restrict nested virtualization to trusted workloads only, migrate sensitive or multi-tenant workloads away from unpatched hosts, and schedule reboots or live-patching workflows as required for kernel remediation to take effect.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed package, is a vendor-fixed build. Check distribution security advisories, kernel changelogs, or package metadata for references to this CVE, KVM nSVM, VMLOAD/VMSAVE emulation, or use of vmcb01. Validate whether nested virtualization remains enabled by checking the kvm_amd nested parameter, for example through /sys/module/kvm_amd/parameters/nested where available. If mitigation was chosen instead of patching, confirm nested virtualization is disabled after reboot or module reload. For virtualization hosts, run controlled regression testing of AMD nested virtualization workloads after patching to ensure KVM stability and compatibility.

Typical attack path

1. Gain low-privileged execution in a workload that can access or create nested virtualization.
2. Confirm the underlying platform uses Linux KVM with AMD SVM nested virtualization enabled.
3. Run or control an L2 guest under an L1 hypervisor configuration where VMLOAD/VMSAVE are not intercepted by L1.
4. Trigger VMLOAD or VMSAVE execution from the L2 guest.
5. Cause KVM to use the wrong VMCB during emulation, leading to virtualization-state corruption, host instability, or possible boundary impact.

How to detect it

There are no reliable public indicators that uniquely prove exploitation of this issue. Detection should focus on suspicious use of nested virtualization and host instability on affected AMD KVM systems. Review kernel logs, hypervisor logs, crash dumps, and monitoring telemetry for unexpected KVM/nSVM faults, host kernel oopses, panics, soft lockups, sudden reboots, or workload failures correlated with nested virtualization activity. Investigate newly created or unusual nested hypervisor workloads, especially where VMLOAD/VMSAVE-heavy test code or custom hypervisors were run. If crash dumps are available, analyze stack traces for KVM AMD SVM, nSVM, VMLOAD, VMSAVE, or VMCB handling paths. Absence of these artifacts does not prove safety, because successful exploitation may only manifest as instability and may not leave distinct log evidence.

What your security team should do

• Prioritize patching Linux KVM hosts that run AMD processors and have nested virtualization enabled.
• Inventory hosts exposing nested virtualization and identify whether untrusted workloads can create or control L2 guests.
• If patching cannot be completed quickly, disable AMD KVM nested virtualization unless there is a documented business requirement.
• Restrict nested virtualization capabilities to trusted workloads and administrative users until all affected kernels are fixed.
• Monitor kernel and hypervisor logs for KVM, nSVM, VMLOAD/VMSAVE-related warnings, crashes, oopses, or unexpected host reboots.
• Track vendor advisories for exact fixed kernel versions and ensure the active running kernel has been updated after reboot or live patching.
• Because this is not KEV-listed, has low EPSS, and has no known public exploit, handle as high priority for exposed virtualization infrastructure rather than as an active mass-exploitation emergency.