Una nueva vulnerabilidad en el kernel de Linux, conocida como Zapscape KVM, podría permitir que un atacante con privilegios dentro de una máquina virtual L1 logre escapar del aislamiento provisto por KVM. El objetivo sería ejecutar código en el sistema host, elevando el impacto a nivel de kernel/raíz dentro de la máquina principal.
El problema afecta específicamente a la gestión de memoria sombra (shadow-MMU) en KVM para x86 y se manifiesta cuando la virtualización anidada se expone a invitados que no se pueden considerar confiables. En este artículo explicamos qué es Zapscape KVM, bajo qué condiciones entra en juego, cómo funciona a nivel técnico y qué pasos seguir para mitigar el riesgo.
Qué es Zapscape KVM y por qué es relevante
Zapscape KVM se rastrea como CVE-2026-64561 y apunta al subsistema de memoria sombra de KVM en KVM/x86. Ese componente es el que ayuda a traducir la memoria de invitados anidados mediante tablas de páginas “sombra”, involucradas en la traducción de direcciones de los huéspedes bajo virtualización anidada.
La preocupación principal es que, en ciertos entornos, un invitado L1 con privilegios del kernel (típicamente equivalentes a raíz dentro del invitado) podría iniciar una ruta de ejecución que comprometa la integridad de las estructuras internas de MMU. Cuando la configuración expone la virtualización anidada a invitados no confiables, se abre una vía para salir del aislamiento esperado.
Condiciones que aumentan el riesgo
La vulnerabilidad no es “universal” para cualquier instalación de KVM. La propia divulgación indica que el escenario crítico se da cuando se cumple lo siguiente:
- Hay virtualización anidada expuesta desde el host a un invitado no confiable.
- El atacante dispone de privilegios suficientes dentro del invitado L1, que normalmente equivale a root o a privilegios comparables en el kernel del invitado.
- En sistemas Intel además se requieren condiciones adicionales relacionadas con la configuración de EPT (los “page-walk” con longitudes 4 y 5).
- En AMD, el comunicado señala que no existe una condición equivalente de EPT en el mismo sentido.
También se destaca que QEMU no es el componente vulnerable. La ejecución problemática vive en el código del kernel de KVM y se activa independientemente de la emulación de QEMU.
Cómo funciona Zapscape KVM (explicación técnica sin perderse)
El corazón de Zapscape KVM es un fallo de orden de comprobaciones en KVM dentro de la shadow-MMU bookkeeping que puede desembocar en un use-after-free (uso después de liberar). Este tipo de vulnerabilidad puede permitir continuar operando sobre memoria que ya no es válida.
En concreto, durante el manejo de fallos de página provocados por el invitado, KVM puede:
- reclamar (reclaim) páginas de MMU sombra, y
- invalidar la “raíz” (root) de la MMU sombra que, a la vez, aún podría estar siendo usada por la ruta de atención al fallo.
El problema aparece porque la ruta no vuelve a verificar el estado de la raíz después de ese proceso de reclamo. Como resultado, KVM podría seguir bajo una raíz que ya fue invalidada.
El investigador describe la ruta de explotación como una situación en la que KVM comprueba si la raíz actual está “obsoleta” antes de habilitar nuevas páginas MMU, pero el reclamo posterior puede invalidar esa misma raíz mientras el flujo continúa. Luego, las páginas hijas que se crean heredan el estado inválido y aun así se insertan en la lista activa de páginas MMU.
Posteriormente, al limpiar recursos, es posible que la misma referencia de enlace termine asociada a dos listas a la vez. Con esa inconsistencia, la liberación de la página puede ocurrir mientras permanecen referencias obsoletas, creando un enlace colgante (dangling link) y habilitando escrituras posteriores a la liberación.
¿Existe prueba de concepto y qué muestra?
La divulgación incluye una prueba de concepto pública. El investigador indica que puede usarse para construir una cadena de acciones que termina creando un archivo con nombre /Zapscape dentro del host ejecutando el KVM vulnerable (enfatizando que el comportamiento objetivo es coherente con la idea de ejecución con privilegios elevados en el sistema principal).
Además, el foco de la prueba se centra en AMD nested SVM/NPT sobre Linux 7.1.3. Para pruebas seguras, el investigador recomienda ejecutarla bajo QEMU TCG.
Importante: el informe público no sostiene que la vulnerabilidad haya sido explotada en el mundo real. También se describe como una técnica que no es un exploit “armado” que funcione de forma inmediata en entornos cloud. Para un uso realista, sería necesario ajustar el flujo para mover acciones L1 hacia un módulo del kernel del invitado, además de adaptar el exploit al kernel del host y a detalles de memoria/backends.
Impacto en sistemas y versiones afectadas
Según el registro del National Vulnerability Database, Linux 5.9 y versiones posteriores estarían afectadas hasta que se apliquen las correcciones en releases estables. Se mencionan, entre otras, versiones que aparecen como vulnerables o que requieren revisión de fijación, incluyendo 6.6.148, 6.12.101, 6.18.42 y 7.1.6 (y también una referencia a 7.2-rc5).
También se advierte que el estado de los paquetes depende del seguimiento de cada distribución. En particular, se recuerda que algunos proveedores pueden incluir parches retroportados sin reflejar necesariamente un rebase a la versión “upstream” exacta.
Cómo se corrige: qué hacer para mitigar
El fix ya fue integrado aguas arriba y, según el comunicado, el commit que implementa el cambio fue el 2abd5287f083. La corrección ajusta el orden: la comprobación de “stale-root” se mueve para ejecutarse después de make_mmu_pages_available().
Cuando el reclamo invalida la raíz actual, el código corregido ya no continúa mapeando o adquiriendo páginas bajo una raíz inválida. En su lugar, reinicia el flujo usando RET_PF_RETRY, forzando una re-ejecución segura de la ruta de manejo del fallo.
En términos prácticos, la recomendación es clara: si administras hosts KVM que podrían exponer virtualización anidada a invitados no confiables, actualiza a un kernel estable corregido o a un paquete del proveedor que haya incorporado el backport del parche.
Atención al estado de paquetes por distribución
Como referencia del 6 de agosto de 2026, el rastreador de Debian mostraba kernels de distintas ramas (como bullseye, bookworm y trixie) marcados como vulnerables según el seguimiento de repositorios de seguridad. Asimismo se señalaba que forky también figuraba como vulnerable, mientras que sid aparecía como corregido en una versión concreta (7.1.6-1).
La moraleja es que no basta con mirar “la versión del kernel” de manera genérica: conviene verificar el estado del tracker del proveedor, el repo de seguridad y el paquete exacto instalado.
Riesgo CVSS y clasificación del fallo
En el asesoramiento de Red Hat se asignó una puntuación preliminar de 7.0 y se clasificó el problema como CWE-825, correspondiente a “expired pointer dereference” (referencia de puntero caducada). Esta clasificación encaja con la naturaleza de la falla descrita: memoria o referencias internas que dejan de ser válidas y aun así se siguen usando.
Línea de tiempo de la divulgación
El investigador reportó la vulnerabilidad a security@kernel.org el 11 de julio de 2026. Posteriormente:
- Se publicó y fusionó un parche el 21 de julio.
- Se envió la información a la lista linux-distros el 1 de agosto con un embargo de cinco días.
- Se asignó CVE-2026-64561 el 4 de agosto.
- La divulgación pública ocurrió el 6 de agosto.
El reporte también menciona el trabajo previo del investigador en otras fallas de escape relacionadas con KVM, como Januscape (CVE-2026-53359) y ITScape (CVE-2026-46316), reforzando que se trata de un área donde la gestión de shadow-MMU y el flujo de fallos de página pueden tener implicaciones de seguridad.
Conclusión
Zapscape KVM es una vulnerabilidad seria en el kernel de Linux que apunta a la gestión de memoria sombra en KVM/x86. Bajo condiciones concretas —virtualización anidada expuesta a invitados no confiables y privilegios suficientes dentro del invitado L1— un atacante podría forzar una ruta que lleve a use-after-free y termine habilitando acciones sobre el host.
Si operas infraestructura con KVM, revisa hoy mismo el estado de tus kernels y paquetes: aplica la actualización a la versión estable corregida o el backport del proveedor. En virtualización, los detalles de configuración importan tanto como las versiones; por eso, además de parchear, valida que no estés habilitando virtualización anidada para invitados que no puedas confiar.
Fuente: https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
