CVE-2026-89930 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
KVM : nVMX : Traitement des vidanges locales de la TLB en cas d'échec de l'entrée VM imbriquée (nested VM-Enter)
KVM traite les vidanges locales de la TLB lors des sorties VM imbriquées « complètes » (via __nested_vmx_vmexit()), mais pas si une entrée VM imbriquée échoue (par exemple, en raison d'échecs des vérifications du VMCS dans nested_vmx_enter_non_root_mode()).
Cependant, il est possible que KVM ait mis en file d'attente des vidanges de TLB qui doivent être exécutées, même si l'entrée VM imbriquée n'a pas abouti. Par exemple, si le VPID est désactivé pour L2 (via nested_vmx_transition_tlb_flush(), ou via les listes de chargement MSR, comme l'indique le SDM :
Si un MSR est chargé d'une manière qui exigerait architecturalement une vidange de la TLB, les TLB sont mises à jour afin qu'après l'entrée VM, le processeur logique n'utilise aucune traduction mise en cache avant la transition.
Le SDM est imprécis quant au moment où la vidange de la TLB doit se produire et sur le fait qu'une entrée VM échouée provoque ou non une vidange de la TLB ; il est donc plus sûr d'effectuer systématiquement cette vidange dans ce cas.
Plus concrètement, KVM met également à jour le dernier VPID utilisé par L1 pour L2 dans nested_vmx_transition_tlb_flush() (c'est-à-dire last_vpid), même si l'entrée VM échoue finalement. Avec le code actuel, KVM pourrait manquer une vidange de TLB si L1 modifie le VPID de L2, puis effectue une entrée VM qui échoue suivie d'une entrée VM réussie, car l'échec de l'entrée VM mettrait à jour last_vpid sans toutefois effectuer réellement la vidange de la TLB. Le traitement des vidanges locales de la TLB en cas d'échec des entrées VM garantit que la TLB est toujours vidée lorsque last_vpid est mis à jour.
VulDB is the best source for vulnerability data and more expert information about this specific topic.