Описание
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.
A flaw was found in the Kernel-based Virtual Machine (KVM) subsystem. This vulnerability occurs when KVM reuses a Virtual Processor ID (VPID) without properly flushing Translation Lookaside Buffer (TLB) entries. A malicious guest virtual machine (VM) could potentially exploit this to access stale TLB entries from a previous VM or virtual CPU, leading to information disclosure or privilege escalation.
Отчет
This vulnerability is rated as an Important impact because the failure to invalidate stale hardware translation cache entries during nested VMX transitions can allow an L1 or L2 guest to access memory mappings belonging to another virtual context. Although this flaw allows potential cross-VM data exposure or privilege elevation, exploitation is restricted to systems where nested Intel virtualization is explicitly utilized. Additionally, successful triggering depends on specific hypervisor state transitions where nested VMX is disabled and re-enabled, and the host reallocates an un-flushed processor identifier. Standard virtualized environments that do not configure or expose nested hardware virtualization are unaffected by this flaw.
Меры по смягчению последствий
Disable nested virtualization on Intel KVM hosts if nested virtual machines are not required.
- Create or modify the module configuration file to disable the nested feature:
echo "options kvm_intel nested=0" > /etc/modprobe.d/kvm_intel.conf
- Apply the configuration by removing and reloading the kvm_intel module:
modprobe -r kvm_intel
modprobe kvm_intel
Warning: Reloading the kvm_intel kernel module requires stopping all active virtual machines on the host. If virtual machines cannot be stopped immediately, reboot the host system to apply the configuration. Caveat: Disabling nested virtualization prevents virtual machines from running their own nested hypervisors (L2 guests).
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 9 | kernel | Affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Affected | ||
| Red Hat OpenShift Container Platform 5 | openshift/ose-rhel-coreos-9 | Affected |
Показывать по
Дополнительная информация
Статус:
8.8 High
CVSS3
Связанные уязвимости
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.
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.
In the Linux kernel, the following vulnerability has been resolved: K ...
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.
8.8 High
CVSS3