CVE-2026-89929 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
KVM : nVM : S'assurer que INVVPID est émulé sur le bon CPU physique
Lors de l'émulation d'INVVPID, KVM exécute INVVPID sur le CPU physique en utilisant vpid02 (au lieu du VPID attribué à L1), après avoir effectué certaines validations sur les opérandes. Cependant, il est possible que le CPU physique sur lequel KVM exécute INVVPID soit différent de celui sur lequel s'exécute L2.
Par exemple, dans le scénario suivant : - L2 s'exécute sur le CPU #1 et sort vers L1 (vmx->nested.vmcs02.cpu=1) - L1 migre vers le CPU #2 et exécute INVVPID - KVM exécute INVVPID sur le CPU #2 - L1 revient sur le CPU #1 et relance L2 (vmx->nested.vmcs02.cpu=1)
Les entrées de la TLB sur le CPU #1 ne sont jamais invalidées, car INVVPID a été exécutée sur le CPU #2, et vmcs02 n'a jamais tourné sur un pCPU différent (c'est-à-dire que vmx_vcpu_load_vmcs() *ne* demandera pas KVM_REQ_TLB_FLUSH).
S'assurer qu'INVVPID est bien exécutée sur le même pCPU où L2 a été exécuté pour la dernière fois, et si ce n'est pas le cas, revenir à l'effacement de last_vpid=0 afin de déclencher un vidage complet du VPID lors de la prochaine entrée VM imbriquée (car KVM détectera que L1 utilise un VPID différent pour L2). Si L2 finit par s'exécuter sur un pCPU différent, KVID procèdera tout de même au vidage de la TLB via vmx_vcpu_load_vmcs().
Once again VulDB remains the best source for vulnerability data.