CVE-2026-89930

W jądrze Linuksa usunięto następującą lukę:

KVM: nVMX: Obsługa lokalnego opróżniania TLB w przypadku nieudanego zagnieżdżenia VM-Enter

KVM obsługuje lokalne opróżnianie TLB na „pełnych” zagnieżdżonych wyjściach VM (przez
__nested_vmx_vmexit()), ale nie w przypadku niepowodzenia zagnieżdżonego wejścia VM (np. z powodu
nieudane sprawdzenie VMCS w trybie zagnieżdżonym_vmx_enter_non_root_mode()).

Możliwe jest jednak, że KVM umieścił w kolejce opróżnienia TLB, co jest konieczne
wykonane, nawet jeśli zagnieżdżone VM-Enter nie powiodło się. Na przykład
jeśli VPID jest wyłączony dla L2 (poprzez zagnieżdżoną_vmx_transition_tlb_flush() lub jeśli
poprzez listy ładunkowe MSR, jak mówi SDM:

Jeśli jakikolwiek MSR jest ładowany w sposób, który będzie architektonicznie
wymagają opróżnienia TLB, TLB są aktualizowane w taki sposób, że po wejściu na maszynę wirtualną,
procesor logiczny nie będzie korzystał z żadnych tłumaczeń, które były wcześniej buforowane
przejście.

SDM nie jest jasne, kiedy powinno nastąpić przepłukanie TLB i czy
żaden nieudany wpis maszyny wirtualnej nie spowodowałby opróżnienia TLB, więc bezpieczniej jest zawsze
w tym przypadku wykonaj kolor TLB.

Mówiąc dokładniej, KVM aktualizuje również ostatni identyfikator VPID L1 używany dla L2
zagnieżdżona_vmx_transition_tlb_flush() (tj. last_vpid), nawet jeśli wpis VM
ostatecznie kończy się niepowodzeniem. Przy obecnym kodzie KVM może przegapić kolor TLB, jeśli
L1 zmienia identyfikator VPID L2, następnie wprowadza nieudany wpis do maszyny wirtualnej, po którym następuje a
udany, ponieważ nieudany wpis maszyny wirtualnej zaktualizuje last_vpid, ale nie
faktycznie opróżnij TLB. Obsługa lokalnego opróżniania TLB w przypadku nieudanych wpisów maszyny wirtualnej
upewnia się, że TLB jest zawsze opróżniany podczas aktualizacji last_vpid.