CVE-2026-89930: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter

Published Sep 16, 2026
·
Updated

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 nestedvmxvmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nestedvmxenternonrootmode()).

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 nestedvmxtransitiontlbflush(), 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 nestedvmxtransitiontlbflush() (i.e. lastvpid), 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 lastvpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when lastvpid is updated.

Affected Software

1 affected component
Kernel.org Linux kernel

Event History

Sep 16, 2026
CVE Published
via MITRE·10:32 AM
Data Sourced
via MITRE·10:32 AM
Description

Frequently Asked Questions

1

Which deployments are relevant to this issue?

The issue is relevant to Linux KVM deployments using nested VMX, where an L1 guest runs an L2 guest. It concerns cases in which an attempted entry into L2 fails while KVM has pending local TLB flush work.

2

What conditions can lead to a missed TLB flush?

The described cases include L2 running without VPID and MSR load-list changes that architecturally require a TLB flush. A failed nested VM entry, such as one caused by failed VMCS checks, can leave that required flush unserviced in the affected behavior.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203