CVE-2026-99120

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

KVM: x86/mmu: Radzi sobie z ustawieniem bitu SS w kodach wyjścia #NPF

Podczas uruchamiania funkcji Hyper-V w systemie Windows 11 KVM widzi ustawiony bit SS
w kodach błędów zagnieżdżonych stron utworzonych dla cieniowanego NPT. AMD
instrukcja nie jest jasna co do tego, kiedy SS jest ustawione, w tym czy można to ustawić
gdy w polu MISC_CTL nie ustawiono opcji SupervisorShadowStackEn (bit 6).
z VMCB.

Niemniej jednak nieoczekiwany bit SS powoduje dostęp poza granicami
pozwolenie_fault(), postrzegane jako raporty WARN lub UBSAN:

jądro: UBSAN: indeks tablicy poza granicami w arch/x86/kvm/mmu.h:225:27
jądro: indeks 34 jest poza zakresem dla typu „u16 [16]”

(w tym przypadku kod błędu strony to 34*2=0x44, czyli SS|U;
raport pokazuje, że SS|U|W również się dzieje). Napraw obsługę nieznanych
kody błędów poprzez upuszczenie SS i (z WARN) wszelkich bitów, które nie należą do tych
które pozwolenie_fault() oczekuje otrzymać.

Jednocześnie, biorąc pod uwagę niepewność co do tego, kiedy sprzęt ustawi SS,
konstruując błąd, śledź zachowanie procesora
kod i zachowaj bit SS przekazany do FNAME(walk_addr_generic).
Chociaż zachowanie jest zaskakujące, istnieje możliwość, że Hyper-V
tego oczekuje (Hyper-V nawet nie włącza CET, chyba że znajdzie MBEC/GMET!),
więc zachowaj tę informację, zgłaszając usterkę do L1 zamiast
bezwarunkowo go odrzucając.

Bisekcja pokazuje, że zaczęło się to dziać po zatwierdzeniu 687ee95c1b6d („KVM:
nSVM: włącz GMET dla gości”), mimo że SHSTK był dostępny dla gości
od Linuksa 6.18. Nie dzieje się tak jednak dlatego, że bit 1 MISC_CTL (GMET)
w jakiś sposób umożliwia raportowanie bitu SS; raczej jest to po prostu Hyper-V
nigdy nie używa CET, chyba że GMET jest również obecny. WARN jest powtarzalny
nawet przy gmet=0, z pewnym hackowaniem zestawu testowego cet.c kvm-unit-tests
aby mieć pewność, że pierwszy dostęp do stosu cieni wywoła błąd strony.