CVE-2026-43133: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation
Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01.
As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
The issue applies to Linux kernel KVM deployments using nested SVM (nSVM). The affected path is reached when an L2 guest executes VMSAVE or VMLOAD and L1 does not intercept that instruction.
What access or conditions are required for exploitation?
An attacker needs local, low-complexity access in an affected nested-virtualization environment. They must be able to cause an L2 guest to execute VMSAVE or VMLOAD without interception by the L1 guest.
What should operators do if they cannot immediately patch?
No temporary mitigation is specified in the provided data. The described trigger depends on L2 execution of VMLOAD or VMSAVE without L1 interception, so limiting that condition can reduce exposure until a kernel containing the referenced stable fixes is deployed.
How can I determine whether a system is affected?
Check whether the system runs the Linux kernel with KVM nested SVM enabled and hosts nested guests. The provided data does not identify affected kernel version ranges, so compare the deployed kernel's fixes against the referenced stable commits rather than relying on a version number.