CVE-2026-46113 in Linux
Resumen
por VulDB • 2026-05-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
KVM: x86: Corrección del uso tras la liberación (use-after-free) en el paginado sombra debido a un GFN inesperado
La MMU sombra calcula los GFN para las páginas sombra directas utilizando sp->gfn más el índice SPTE. Esta suposición falla en el paginado sombra si las tablas de páginas del invitado se modifican entre las entradas de la máquina virtual (similar al commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). El flujo es el siguiente:
- Se instala un PDE para un mapeo de 2 MB y se accede a una página en esa área. KVM crea un kvm_mmu_page compuesto por 512 páginas de 4 KB; el kvm_mmu_page está marcado por FNAME(fetch) como mapeo directo porque el mapeo del invitado es una página enorme (y por lo tanto contigua).
- El mapeo del PDE se cambia desde fuera del invitado.
- El invitado accede a otra página en la misma área de 2 MB. KVM instala un nuevo SPTE hoja y una entrada rmap; el SPTE utiliza el GFN "correcto" (es decir, basado en el nuevo mapeo, tal como se cambió en el paso anterior), pero ese GFN está fuera del rango [sp->gfn, sp->gfn + 511]; por lo tanto, la entrada rmap no se puede encontrar y eliminar cuando se borra (zaps) el kvm_mmu_page.
- Se elimina el memslot que cubre el primer mapeo de 2 MB y se borra el kvm_mmu_page para la GPA ahora inválida. Sin embargo, rmap_remove() solo busca en el rango [sp->gfn, sp->gfn + 511] establecido en el paso 1 y no logra encontrar la entrada rmap que fue registrada en el paso 3.
- Cualquier operación que cause un recorrido de rmap para la misma página accedida en el paso 3 entonces recorre un rmap obsoleto y desreferencia un kvm_mmu_page ya liberado. Esto incluye el registro de suciedad (dirty logging) o las invalidaciones del notificador de la MMU (por ejemplo, desde MADV_DONTNEED).
El problema subyacente es que el recorrido de los PTE sombra por parte de KVM asume que si un SPTE está presente cuando KVM quiere instalar un SPTE no hoja, entonces el kvm_mmu_page existente debe ser para el gfn correcto. Dado que la única manera de que el gfn sea incorrecto es si KVM cometió un error y no logró borrar un SPTE... lo cual no debería suceder, pero *en realidad* solo ocurre en respuesta a una escritura del invitado.
Ese bug existe literalmente desde siempre, ya que incluso la primera versión de KVM asume que el GFN coincide y recorre la "página sombra" incorrecta. Sin embargo, eso solo era una imprecisión hasta que llegó 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages").
Se corrige verificando una discrepancia en el gfn objetivo y borrando el SPTE existente. De esta manera, el SP antiguo y las entradas rmap desaparecen, KVM instala el rmap en la ubicación correcta y todo funciona correctamente.
If you want to get best quality of vulnerability data, you may have to visit VulDB.