CVE-2026-98715

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

KVM: SVM: Zachowaj kontrolę TLB (tj. oczekujące opróżnienie TLB) w przypadku awarii VMRUN

Nie resetuj kontroli TLB VMCB z powrotem do „nic nie rób” w przypadku nieudanego VMRUN,
ponieważ testy empiryczne pokazują, że procesor wykonuje żądane opróżnianie TLB, jeśli
i tylko wtedy, gdy VMRUN zakończy się sukcesem, tj. wyczyszczeniem kontroli TLB w przypadku niepowodzenia
VMRUN skutecznie wyrzuca kolor TLB.

Jawnie śledź potrzebę opróżnienia wszystkich identyfikatorów ASID w przeliczeniu na procesor, jako
Warunek ponownego użycia ASID jest powiązany z procesorem pCPU, a nie z procesorem vCPU. Jako bonus,
eliminuje to również potrzebę unikania mieszania się z FLUSH_ALL_ASID
TLB_Control_FLUSH_ASID, np. w svm_flush_tlb_asid().

Celowo nie zawracaj sobie głowy zapisywaniem/przywracaniem „starego” tlb_ctl w przypadku niepowodzenia,
w cudzysłowie, ponieważ to nie jest dokładnie stary tlb_ctl, to tlb_ctl z
po pre_svm_run(), ale przed aktualizacją tlb_ctl dla Flush_all_asids. Jeśli
VMRUN kończy się niepowodzeniem i wymuszony zostaje TLB_Control_FLUSH_ALL_ASID, potem następny
pomyślne uruchomienie VMCB *może* niepotrzebnie opróżnić wszystkie ASID, które
ściśle rzecz biorąc, może to skutkować problemami z głośnymi sąsiadami. Jednakże,
fakt, że funkcja new_asid() jest już uruchamiana przez gościa ze względu na wadę KVM
zachowanie polegające na czyszczeniu ASID na emulowanym INIT, oznacza, że gość może
już wywołuje kolor wszystkich ASID w mniej więcej tym samym tempie. I raz
KVM przestaje zakłócać ASID w emulowanym INIT, *lub* przypisuje statyczny ASID
dla każdego vCPU ta wada znika.