Exploit Januscape: use-after-free en KVM con nested virtualization

En el hipervisor KVM del kernel de Linux se ha identificado una vulnerabilidad de tipo use-after-free (CVE-2026-53359) que permite, desde una máquina virtual invitada, corromper el estado de las páginas en sombra del kernel del host. El código vulnerable ha estado presente en el kernel desde 2010, es decir, unos 16 años. Un PoC-exploit público denominado Januscape demuestra una caída fiable del host, lo que provoca una denegación de servicio para todas las máquinas virtuales del servidor físico. El problema afecta a hosts x86 con procesadores Intel y AMD con virtualización anidada activada. Existe un parche disponible: los administradores de entornos KVM multitenant deberían aplicar la corrección con carácter prioritario.

Esencia técnica de la vulnerabilidad

El fallo se encuentra en el código de la shadow MMU, el mecanismo de tablas de páginas en sombra que KVM utiliza para rastrear la memoria de las máquinas invitadas. Cuando necesitaba reutilizar una página en sombra existente, KVM la hacía corresponder únicamente por la dirección del frame de memoria (GFN), pero no comprobaba el tipo (rol) de esa página. Dos tipos distintos de páginas en sombra pueden compartir la misma dirección, pero desempeñar funciones completamente diferentes. Esto provocaba que KVM pudiera reutilizar una página de tipo incorrecto, rompiendo la integridad interna de sus estructuras de datos.

En la mayoría de los casos, el kernel detecta la corrupción y termina de forma abrupta; esto es precisamente lo que demuestra el PoC público Januscape: un módulo de kernel cargable en la VM invitada dispara un pánico en el host tras segundos o minutos de carrera. Sin embargo, existe un escenario aún más peligroso: si la página en sombra liberada llega a ser reasignada para otros fines antes de su limpieza, el procedimiento de limpieza escribe un valor en una memoria que ya no le pertenece. Según el investigador, el atacante controla dónde se produce la escritura, aunque no controla el valor escrito, pero incluso este primitivo limitado puede ser suficiente para una escalada posterior.

El código vulnerable fue introducido por el commit 2032a93d66fa en agosto de 2010 (época del kernel 2.6.36). La corrección —el commit 81ccda30b4e8— fue aceptada en la rama principal el 19 de junio de 2026. El autor del parche es el mantenedor de KVM Paolo Bonzini. La corrección consiste en una adición de una sola línea a la función kvm_mmu_get_child_sp(): la condición para la reutilización ahora verifica role.word junto con el GFN.

Condiciones de explotación y alcance de la amenaza

Para la explotación son necesarias dos condiciones del lado de la máquina invitada:

• Privilegios de root dentro de la VM, un requisito habitual para instancias de nube arrendadas.
• Virtualización anidada (nested virtualization) activada en el host. Incluso si el host utiliza por defecto EPT (Intel) o NPT (AMD) por hardware, la virtualización anidada obliga a KVM a emplear la ruta heredada (legacy) a través de la shadow MMU, donde reside el fallo.

El exploit no requiere interacción con QEMU ni con otro VMM en espacio de usuario: es un fallo puramente intra-kernel de KVM. El riesgo práctico se concentra en entornos x86 que alojan inquilinos no confiables con acceso a virtualización anidada. Un atacante que alquile una de estas instancias es capaz de hacer caer el host y dejar fuera de servicio todas las máquinas virtuales vecinas en el mismo servidor físico.

Según el investigador, en distribuciones como RHEL, donde /dev/kvm tiene permisos 0666 (accesible a todos los usuarios), el mismo fallo podría potencialmente utilizarse para una escalada local de privilegios hasta root, aunque el vector principal de amenaza es la fuga desde la máquina invitada.

Cabe señalar que CVE-2026-53359 es ya la segunda vulnerabilidad de tipo use-after-free en la shadow MMU en dos meses. En mayo de 2026 se corrigió un problema similar, pero distinto, CVE-2026-46113, relacionado con una discrepancia en la rmap en el mismo código heredado. Esto apunta a la fragilidad sistémica de la ruta legacy de la shadow MMU.

Contexto: serie de revelaciones de un mismo investigador

Januscape es la tercera vulnerabilidad del kernel de Linux revelada por el investigador Hyunwoo Kim (@v4bel) en aproximadamente dos meses. En mayo de 2026 publicó Dirty Frag (CVE-2026-43284 / CVE-2026-43500), una cadena de vulnerabilidades de escritura en la caché de páginas. En junio le siguió ITScape (CVE-2026-46316), la primera fuga desde una máquina invitada en KVM/arm64 demostrada públicamente mediante una condición de carrera en el controlador de interrupciones virtual. Januscape completa el panorama desde el lado x86.

Según Kim, el exploit fue presentado como hallazgo de día cero en el programa Google kvmCTF, lanzado en 2024 y que ofrece recompensas de hasta 250 000 dólares por una fuga completa desde la máquina invitada. Sin embargo, esta afirmación no ha sido confirmada por Google en fuentes abiertas.

Recomendaciones prácticas

Las versiones estables del kernel con la corrección se publicaron el 4 de julio de 2026:

• 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

Acciones prioritarias:

1. Compruebe la presencia del parche. Asegúrese de que el kernel contiene el commit 81ccda30b4e8. Los backports de los distribuidores pueden incluir la corrección bajo otro número de versión; revise el changelog del paquete y no solo la salida de uname -r.
2. Si no es posible actualizar de inmediato, desactive la virtualización anidada para invitados no confiables mediante los parámetros del módulo: kvm_intel.nested=0 o kvm_amd.nested=0. Esto elimina por completo el vector de ataque.
3. Evalue la configuración de acceso a /dev/kvm. En sistemas donde este archivo de dispositivo está disponible para todos los usuarios, considere restringir sus permisos de acceso.

NVD aún no ha asignado una puntuación CVSS a CVE-2026-53359. Los hosts ARM64 no están afectados por esta vulnerabilidad — ITScape (CVE-2026-46316) constituye un problema aparte para KVM/arm64.

El PoC público demuestra una caída fiable del host, y dos vulnerabilidades en la shadow MMU en dos meses señalan una deuda técnica acumulada en el código heredado de KVM. Los administradores de hosts KVM x86 con virtualización anidada y acceso multitenant deberían considerar la actualización del kernel a una versión corregida como una tarea de alta prioridad, sin esperar a que se asigne una puntuación CVSS.