CVE-2026-89930 in Linux
Sumário
de VulDB • 16/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
KVM: nVMX: Processar flushing locais de TLB em falhas na entrada aninhada da VM (nested VM-Enter)
O KVM processa flushes locais de TLB nas saídas aninhadas "completas" da VM (através de `__nested_vmx_vmexit()`), mas não o faz se uma entrada aninhada da VM falhar (por exemplo, devido à falha das verificações do VMCS em `nested_vmx_enter_non_root_mode()`).
No entanto, é possível que o KVM tenha flushes de TLB enfileirados que precisam ser executados, mesmo que a entrada aninhada da VM não tenha sido bem-sucedida. Por exemplo, se o VPID estiver desabilitado para L2 (via `nested_vmx_transition_tlb_flush()`, ou através das listas de carregamento de MSR, conforme diz o SDM:
Se algum MSR está sendo carregado de uma maneira que arquitetonicamente exigiria um flush da TLB, as TLBs são atualizadas para que, após a entrada na VM, o processador lógico não utilize nenhuma tradução que estava em cache antes da transição.
O SDM é pouco claro sobre quando o flush da TLB deve ocorrer e se uma falha na entrada da VM causaria ou não um flush da TLB; portanto, é mais seguro sempre realizar o flush da TLB neste caso.
Mais concretamente, o KVM também atualiza a última VPID usada por L1 para L2 em `nested_vmx_transition_tlb_flush()` (ou seja, `last_vpid`), mesmo que a entrada na VM falhe no final. Com o código atual, o KVM poderia perder um flush da TLB se L1 alterasse a VPID de L2 e depois realizasse uma entrada na VM com falha seguida por uma bem-sucedida, pois a entrada com falha atualizaria `last_vpid`, mas não executaria efetivamente o flush da TLB. Processar os flushes locais de TLB em entradas na VM que falham garante que a TLB seja sempre flushed quando `last_vpid` é atualizado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.