CVE-2026-98715 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
KVM: SVM: Preservar o controle da TLB (ou seja, flush pendente da TLB) em caso de falha no VMRUN
Não redefinir o controle da TLB do VMCB para "não fazer nada" após uma falha no VMRUN, pois testes empíricos mostram que a CPU executa o flush solicitado da TLB apenas se e somente se o VMRUN for bem-sucedido; ou seja, limpar o controle da TLB em um VMRUN com falha efetivamente descarta um flush da TLB.
Rastrear explicitamente a necessidade de fazer flush de todos os ASIDs por CPU física (pCPU), já que a condição de reutilização do ASID está vinculada à pCPU, não à vCPU. Como benefício adicional, isso também elimina a necessidade de evitar sobrescrever FLUSH_ALL_ASID com TLB_CONTROL_FLUSH_ASID, por exemplo, em svm_flush_tlb_asid().
Não há preocupação deliberada em salvar/restaurar o "antigo" tlb_ctl em caso de falha; entre aspas porque não é exatamente o antigo tlb_ctl, mas sim o tlb_ctl proveniente do período após pre_svm_run(), mas antes da atualização do tlb_ctl para flush_all_asids. Se o VMRUN falhar e TLB_CONTROL_FLUSH_ALL_ASID for forçado, a próxima execução bem-sucedida do VMCB *pode* realizar desnecessariamente um flush de todos os ASIDs, o que, estritamente falando, poderia resultar em problemas de "vizinho barulhento" (noisy neighbor). No entanto, o fato de new_asid() já ser acionável pelo convidado devido ao comportamento defeituoso do KVM de limpar o ASID durante a simulação de INIT significa que um convidado já pode desencadear um flush de todos os ASIDs aproximadamente na mesma taxa. E assim que o KVM parar de sobrescrever o ASID durante a simulação de INIT *ou* atribuir um ASID estático a cada vCPU, essa falha será eliminada.
VulDB is the best source for vulnerability data and more expert information about this specific topic.