In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Always flush vpid02 on first use
Make sure vpid02 is always flushed on first use by setting last_vpid=0
when allocating vpid02. nested_vmx_transition_tlb_flush() will always
detect a VPID change on first VM-Enter after VMXON, because VPID=0 in
vmcs12 is not allowed if L1 enables VPID.
This avoids using stale TLB entries from a previous lifetime of the
VPID, that might have been associated with a different vCPU (or a
completely different VM).
Note that last_vpid is already being initialized as 0 when the vCPU is
created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the
problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM
happens to reuse a VPID that has TLB entries on the physical CPU.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 8.8
AV:L - Reached when an L1 nested-VMX guest executes VMXOFF then VMXON and VMLAUNCH/VMRESUME on the host KVM_RUN path (handle_vmxon/enter_vmx_operation into nested_vmx_transition_tlb_flush); no network, adjacent-radio, or physical path hits nVMX VPID allocation.
AC:L - The L1 attacker fully controls VMXOFF, VMXON, vmcs12 VPID, and vCPU pinning; allocate_vpid() is a deterministic global bitmap, nested VMX and VPID are default, and skipping last_vpid=0 makes the omitted INVVPID on first VM-Enter after VMXON reliably hit.
PR:L - Needs /dev/kvm and nested VMX, typically a kvm-group user or cloud tenant running QEMU, not init-namespace root; handle_vmxon() only checks guest CPL=0 and CR4.VMXE, and KVM create/run ioctls have no CAP_SYS_ADMIN gate.
UI:N - Once the attacker has a nested-capable VM, they trigger the flaw with their own VMXOFF/VMXON and VMLAUNCH; no separate victim action such as attaching a device or mounting a filesystem is required.
S:C - Skipping the vpid02 INVVPID lets L2 use stale hardware TLB entries from a previous lifetime of that VPID, including another vCPU or a different VM, crossing KVM guest isolation so impact is outside L1's security authority.
C:H - Reused vpid02 linear or combined TLB entries can translate L2 loads onto another VM's or recycled host physical pages, giving a read primitive over co-resident guest memory rather than a bounded pointer leak.
I:H - The same stale translations apply to stores, so L2 can write through another VM's cached GPA/HPA mappings, corrupting co-resident guest memory and enabling control-flow hijack in the victim VM or further host compromise if pages were reused.
A:H - Stale VPID hits produce wrong translations that surface as KVM internal/emulation failures and can oops or panic the host when walks land on recycled or unmapped host pages, denying service to the hypervisor and co-located VMs.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - Reached when an L1 nested-VMX guest executes VMXOFF then VMXON and VMLAUNCH/VMRESUME on the host KVM_RUN path (handle_vmxon/enter_vmx_operation into nested_vmx_transition_tlb_flush); no network, adjacent-radio, or physical path hits nVMX VPID allocation.
AC:L - The L1 attacker fully controls VMXOFF, VMXON, vmcs12 VPID, and vCPU pinning; allocate_vpid() is a deterministic global bitmap, nested VMX and VPID are default, and skipping last_vpid=0 makes the omitted INVVPID on first VM-Enter after VMXON reliably hit.
PR:L - Needs /dev/kvm and nested VMX, typically a kvm-group user or cloud tenant running QEMU, not init-namespace root; handle_vmxon() only checks guest CPL=0 and CR4.VMXE, and KVM create/run ioctls have no CAP_SYS_ADMIN gate.
UI:N - Once the attacker has a nested-capable VM, they trigger the flaw with their own VMXOFF/VMXON and VMLAUNCH; no separate victim action such as attaching a device or mounting a filesystem is required.
S:C - Skipping the vpid02 INVVPID lets L2 use stale hardware TLB entries from a previous lifetime of that VPID, including another vCPU or a different VM, crossing KVM guest isolation so impact is outside L1's security authority.
C:H - Reused vpid02 linear or combined TLB entries can translate L2 loads onto another VM's or recycled host physical pages, giving a read primitive over co-resident guest memory rather than a bounded pointer leak.
I:H - The same stale translations apply to stores, so L2 can write through another VM's cached GPA/HPA mappings, corrupting co-resident guest memory and enabling control-flow hijack in the victim VM or further host compromise if pages were reused.
A:H - Stale VPID hits produce wrong translations that surface as KVM internal/emulation failures and can oops or panic the host when walks land on recycled or unmapped host pages, denying service to the hypervisor and co-located VMs.
CVSS 3.1