CVE-2026-98467 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
KVM : arm64 : nv : Correction d'une déréférencement de pointeur NULL lors des opérations nested wp/unmap et du teardown (démantèlement), en raison d'une condition de concurrence.
Le commit 7270cc9157f4 (« KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers ») a introduit l'invalidation de VNCR_EL2 dans les fonctions `kvm_nested_s2_unmap()` et `kvm_nested_s2_wp()`.
Cependant, au moment où cette opération est effectuée, un démantèlement (teardown) concurrent du stage 2 d'une machine invitée nested peut entraîner la définition de `kvm->arch.mmu.pgt` à NULL.
Ce problème se produit dans `kvm_flush_shadow_all()` -> `kvm_arch_flush_shadow_all()` -> `kvm_free_stage2_pgd()`, et est exécuté sous le verrou `kvm->mmu_lock`.
Le commit ec14c272408a (« KVM: arm64: nv: Unmap/flush shadow stage 2 page tables ») a introduit le démantèlement de la plage MMU nested complète, ce qui invoque ensuite `stage2_apply_range()` avec l'indicateur `resched=true` :
``` mmu_notifier_invalidate_range_start() -> ... -> kvm_mmu_notifier_invalidate_range_start() -> kvm_mmu_unmap_gfn_range() -> kvm_unmap_gfn_range() -> kvm_nested_s2_unmap() -> kvm_stage2_unmap_range() -> __unmap_stage2_range() -> stage2_apply_range() ```
Cela signifie que `stage2_apply_range()` peut libérer le verrou `kvm->mmu_lock`, permettant ainsi une progression concurrente en parallèle avec `kvm_arch_flush_shadow_all()`.
Si `kvm_arch_flush_shadow_all()` avance plus loin que `stage2_apply_range()` et termine son opération, cela garantit un déréférencement de pointeur NULL.
Puisque `kvm_free_stage2_pgd()` est exécutée sous le verrou `kvm->mmu_lock`, la valeur sera soit observée comme NULL, soit non-null, et cette action sera sérialisée par rapport à `kvm_free_stage2_pgd()`.
Pour résoudre ce problème, l'invalidation a été abstraite dans une nouvelle fonction, `kvm_invalidate_vncr_ipa_all()`, et il est vérifié que le pointeur `pgt` n'est pas NULL avant de le déréférencer.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.