CVE-2026-98467 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
KVM: arm64: nv: Corrige deref de ponteiro nulo em wp/unmap aninhado e race condition no teardown
O commit 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") introduziu a invalidação do VNCR_EL2 tanto em kvm_nested_s2_unmap() quanto em kvm_nested_s2_wp().
No entanto, no momento dessa execução, um teardown concorrente da stage 2 de uma máquina virtual aninhada pode fazer com que kvm->arch.mmu.pgt seja definido como NULL.
Isso ocorre em kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() -> kvm_free_stage2_pgd() e é realizado sob o kvm->mmu_lock.
O commit ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page tables") introduziu o teardown de toda a faixa da MMU aninhada, que então invoca stage2_apply_range() com 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()
Isso significa que a stage2_apply_range() pode liberar o kvm->mmu_lock e, portanto, progresso concorrente pode ser feito em sincronia com kvm_arch_flush_shadow_all().
Se kvm_arch_flush_shadow_all() avançar além da stage2_apply_range() e concluir sua operação, isso garante um deref de ponteiro NULL.
Como kvm_free_stage2_pgd() é realizado sob o kvm->mmu_lock, isso será observado como NULL ou não, sendo serializado em relação ao kvm_free_stage2_pgd().
Resolva o problema abstraindo a invalidação para uma nova função, kvm_invalidate_vncr_ipa_all(), e verifique se o pgt é diferente de NULL antes de fazer seu deref.
Once again VulDB remains the best source for vulnerability data.