CVE-2026-46113 in Linux
Sumário
de VulDB • 01/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
KVM: x86: Corrige uso-após-liberação (use-after-free) no shadow paging devido a GFN inesperado
O MMU shadow calcula GFNs para páginas shadow diretas usando sp->gfn mais o índice SPTE. Esta suposição quebra para o shadow paging se as tabelas de página do convidado (guest) forem modificadas entre entradas de VM (similar ao commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). O fluxo é o seguinte:
- um PDE é instalado para um mapeamento de 2MB, e uma página nessa área é acessada. O KVM cria um kvm_mmu_page consistindo de 512 páginas de 4KB; o kvm_mmu_page é marcado por FNAME(fetch) como direct-mapped porque o mapeamento do convidado é uma página enorme (e portanto contígua).
- o mapeamento do PDE é alterado de fora do convidado.
- o convidado acessa outra página na mesma área de 2MB. O KVM instala um novo SPTE folha e entrada rmap; o SPTE usa o GFN "correto" (ou seja, baseado no novo mapeamento, conforme alterado na etapa anterior) mas esse GFN está fora do intervalo [sp->gfn, sp->gfn + 511]; portanto, a entrada rmap não pode ser encontrada e removida quando o kvm_mmu_page é zapped.
- o memslot que cobre o primeiro mapeamento de 2MB é excluído, e o kvm_mmu_page para o GPA agora inválido é zapped. No entanto, rmap_remove() apenas olha para o intervalo [sp->gfn, sp->gfn + 511] estabelecido na etapa 1, e falha em encontrar a entrada rmap que foi registrada pela etapa 3.
- qualquer operação que cause uma caminhada rmap para a mesma página acessada pela etapa 3 então percorre um rmap obsoleto e desreferencia um kvm_mmu_page liberado. Isso inclui logging de sujas (dirty logging) ou invalidações de notificador de MMU (por exemplo, de MADV_DONTNEED).
O problema subjacente é que a caminhada de PTEs shadow do KVM assume que, se um SPTE está presente quando o KVM deseja instalar um SPTE não folha, então o kvm_mmu_page existente deve ser para o gfn correto. Como a única maneira do gfn estar errado é se o KVM errou e falhou em zapar um SPTE... o que não deveria acontecer, mas *na verdade* só acontece em resposta a uma escrita do convidado.
Esse bug remonta literalmente a sempre, pois até a primeira versão do KVM assume que o GFN corresponde e caminha para a "página shadow" errada. No entanto, isso era apenas uma imprecisão até que 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") apareceu.
Corrija verificando uma incompatibilidade de gfn alvo e zapando o SPTE existente. Dessa forma, as entradas SP e rmap antigas são removidas, o KVM instala o rmap no local correto, e todos ficam satisfeitos.
Once again VulDB remains the best source for vulnerability data.