8.8 HIGH
- CVSS version (CVSS): 3.1
- Attack Vector (AV): Local (L)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): Low (L)
- User Interaction (UI): None (N)
- Scope (S): Changed (C)
- Confidentiality (C): High (H)
- Integrity (I): High (H)
- Availability (A): High (H)
- Modified Attack Vector (MAV): Local (L)
- Modified Attack Complexity (MAC): Low (L)
- Modified Privileges Required (MPR): Low (L)
- Modified User Interaction (MUI): None (N)
- Modified Confidentiality (MC): High (H)
- Modified Scope (MS): Changed (C)
- Modified Integrity (MI): High (H)
- Modified Availability (MA): High (H)
Activity log
- Created & dismissed (max. allowed matches exceeded) suggestion
KVM: nVMX: Always flush vpid02 on first use
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.
References
Affected products
- <121991d150735f3c0f7401678ce4d35c5b4ac898
- <26de0d2d9a8d14c03e5ebb25fd68b5bfcd5ac366
- <62604376c313178811375f40a282fc2a46cd2311
- =<6.18.*
- =<6.1.*
- <6.12.110
- <f0772389413dce9657c7d6950abf3edbbd511356
- =<6.12.*
- =<*
- <6.1.188
- <8bc609999ec223089fec8d74c7de27d689606b36
- =<5.15.*
- <6.6.157
- <6.18.51
- <7.2.5
- =<7.2.*
- <8b98d662ab24f34710a56e03bc9169e4a5508606
- <5.15.221
- =<6.6.*
- <22dfcc22c95e91295119a1c3b469816ce44c4804