Descripción
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: nVMX: Atender los vaciados locales de TLB cuando falla un VM-Enter anidado KVM atiende los vaciados locales de TLB en los VM-Exits anidados "completos" (mediante __nested_vmx_vmexit()), pero no cuando falla un VM-Enter anidado (por ejemplo, debido a comprobaciones fallidas de VMCS en nested_vmx_enter_non_root_mode()). Sin embargo, es posible que KVM haya encolado vaciados de TLB que deban realizarse, incluso si el VM-Enter anidado no tuvo éxito. Por ejemplo, si VPID está deshabilitado para L2 (mediante nested_vmx_transition_tlb_flush()), o mediante las listas de carga de MSR, como indica el SDM: 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. El SDM no es claro sobre cuándo debe ocurrir el vaciado de TLB ni si una entrada a VM fallida vaciaría la TLB, por lo que es más seguro realizar siempre el vaciado de TLB en este caso. En concreto, KVM también actualiza el último VPID que L1 usó para L2 en nested_vmx_transition_tlb_flush() (es decir, last_vpid), incluso si la entrada a VM finalmente falla. Con el código actual, KVM podría omitir un vaciado de TLB si L1 cambia el VPID de L2 y luego realiza una entrada a VM fallida seguida de una exitosa, ya que la entrada fallida actualizaría last_vpid sin vaciar realmente la TLB. Atender los vaciados locales de TLB en las entradas a VM fallidas garantiza que la TLB siempre se vacíe cuando se actualiza last_vpid.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a b577a7cd6d984dd430af88ee1c9e03da71b73ee0 · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a c0c66cd575e31218da6a7d104c6ef80b0830b60c · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a 1025b938dc439b75c720a568a855a13eeb245686 · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a 312cdb6d8940827dea63a7a52fb714a5049f06d1 · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a f74fccdf4f7fb0780cd84944108d35f3d9dc46a7 · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a c43563e7518e65ec6ccaa6a65f84c5af5ca5d379 · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a 62c3ee4c9f0e2efef5157358b3549e50ede96d73 · 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 y anteriores a 05a0b701d1089fb57beeb8982f23c3bbafe0fa8b
- Linux Afectadas: 4.4 No afectadas: 5.10.273 · 5.15.221 · 6.1.188 · 6.6.157 · 6.12.110 · 6.18.51
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/b577a7cd6d984dd430af88ee1c9e03da71b73ee0
- Referencia en git.kernel.orggit.kernel.org/stable/c/c0c66cd575e31218da6a7d104c6ef80b0830b60c
- Referencia en git.kernel.orggit.kernel.org/stable/c/1025b938dc439b75c720a568a855a13eeb245686
- Referencia en git.kernel.orggit.kernel.org/stable/c/312cdb6d8940827dea63a7a52fb714a5049f06d1
- Referencia en git.kernel.orggit.kernel.org/stable/c/f74fccdf4f7fb0780cd84944108d35f3d9dc46a7
- Referencia en git.kernel.orggit.kernel.org/stable/c/c43563e7518e65ec6ccaa6a65f84c5af5ca5d379
- Referencia en git.kernel.orggit.kernel.org/stable/c/62c3ee4c9f0e2efef5157358b3549e50ede96d73
- Referencia en git.kernel.orggit.kernel.org/stable/c/05a0b701d1089fb57beeb8982f23c3bbafe0fa8b
Ver el texto original en inglés (CVE.org)
KVM: nVMX: Service local TLB flushes on failed nested VM-Enter
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.