In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Service local TLB flushes on failed nested VM-Enter
KVM services local TLB flushes on "full" nested VM-Exits (through
__nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to
failed VMCS checks in nested_vmx_enter_non_root_mode()).
However, it is possible that KVM had queued TLB flushes that need to be
performed, even if the nested VM-Enter was not successful. For example,
if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if
via the MSR load lists, as the SDM says:
If any MSR is being loaded in such a way that would architecturally
require a TLB flush, the TLBs are updated so that, after VM entry, the
logical processor will not use any translations that were cached before
the transition.
The SDM is unclear about when the TLB flush should occur, and whether or
not a failed VM entry would flush the TLB, so it is safer to always
do the TLB flush in this case.
More concretely, KVM also updates the last VPID L1 used for L2 in
nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry
ultimately fails. With the current code, KVM could miss a TLB flush if
L1 changes L2's VPID, then does a failed VM entry followed by a
successful one, as the failed VM entry would update last_vpid but not
actually flush the TLB. Servicing local TLB flushes on failed VM entries
makes sure that the TLB is always flushed when last_vpid is updated.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - An L1 nested hypervisor reaches nested_vmx_enter_non_root_mode() by executing VMLAUNCH/VMRESUME (handle_vmlaunch/handle_vmresume) during KVM_RUN, or via KVM_SET_NESTED_STATE; this is local KVM ioctl/guest execution, not a network, adjacent-radio, or physical-device path.
AC:L - L1 fully controls vmcs12, can change virtual_processor_id so nested_vmx_transition_tlb_flush() updates last_vpid and queues KVM_REQ_TLB_FLUSH_GUEST, then fail VM-Enter after that point (invalid guest state or MSR-load list failure) and retry successfully; nested=1 and enable_vpid=1 are kvm_intel defaults, with no attacker-uncontrollable race.
PR:N - Exploitation requires no host root or init-namespace capabilities beyond running nested VMX in a tenant KVM guest; kvm_intel nested=1 is default, so a cloud tenant triggers the bug from guest CPL0 VMLAUNCH without host privileges or special capabilities.
UI:N - No victim user or administrator action is required; the attacker drives the VPID change, the failed nested VM-Enter, and the subsequent successful enter entirely from their own nested-virtualization workload.
S:C - Host KVM fails to INVVPID L2's hardware VPID (vpid02) on a failed nested VM-Enter after last_vpid is updated, so stale guest/combined TLB entries persist across nested contexts and can skip the first-use flush KVM relies on after VPID reuse, crossing the KVM nested guest-to-hypervisor isolation boundary.
C:H - Missed INVVPID leaves stale combined GVA-to-HPA mappings for L2's hardware VPID; after a vpid12 change (or a skipped first-use flush when last_vpid is updated on a failed enter), nested code can read pages L1 already remapped to another L2 or to L1 hypervisor memory, a translation-cache use-after-invalidate disclosure primitive.
I:H - The retained combined mappings remain writable, so L2 (or a later nested guest on the same hardware VPID) can write through stale translations into pages L1 already remapped, yielding a use-after-invalidate write primitive against nested-hypervisor or sibling-guest memory.
A:H - Stale nested TLB entries produce wrong translations that can crash or hang the L1 hypervisor and L2 guests, and inconsistent KVM MMU/VPID state can oops the host; the attacker can repeat the failed-then-successful VM-Enter sequence at will.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - An L1 nested hypervisor reaches nested_vmx_enter_non_root_mode() by executing VMLAUNCH/VMRESUME (handle_vmlaunch/handle_vmresume) during KVM_RUN, or via KVM_SET_NESTED_STATE; this is local KVM ioctl/guest execution, not a network, adjacent-radio, or physical-device path.
AC:L - L1 fully controls vmcs12, can change virtual_processor_id so nested_vmx_transition_tlb_flush() updates last_vpid and queues KVM_REQ_TLB_FLUSH_GUEST, then fail VM-Enter after that point (invalid guest state or MSR-load list failure) and retry successfully; nested=1 and enable_vpid=1 are kvm_intel defaults, with no attacker-uncontrollable race.
PR:N - Exploitation requires no host root or init-namespace capabilities beyond running nested VMX in a tenant KVM guest; kvm_intel nested=1 is default, so a cloud tenant triggers the bug from guest CPL0 VMLAUNCH without host privileges or special capabilities.
UI:N - No victim user or administrator action is required; the attacker drives the VPID change, the failed nested VM-Enter, and the subsequent successful enter entirely from their own nested-virtualization workload.
S:C - Host KVM fails to INVVPID L2's hardware VPID (vpid02) on a failed nested VM-Enter after last_vpid is updated, so stale guest/combined TLB entries persist across nested contexts and can skip the first-use flush KVM relies on after VPID reuse, crossing the KVM nested guest-to-hypervisor isolation boundary.
C:H - Missed INVVPID leaves stale combined GVA-to-HPA mappings for L2's hardware VPID; after a vpid12 change (or a skipped first-use flush when last_vpid is updated on a failed enter), nested code can read pages L1 already remapped to another L2 or to L1 hypervisor memory, a translation-cache use-after-invalidate disclosure primitive.
I:H - The retained combined mappings remain writable, so L2 (or a later nested guest on the same hardware VPID) can write through stale translations into pages L1 already remapped, yielding a use-after-invalidate write primitive against nested-hypervisor or sibling-guest memory.
A:H - Stale nested TLB entries produce wrong translations that can crash or hang the L1 hypervisor and L2 guests, and inconsistent KVM MMU/VPID state can oops the host; the attacker can repeat the failed-then-successful VM-Enter sequence at will.
CVSS 3.1