Explicación de Zapscape y cómo proteger los hosts KVM

La versión resumida

Ir a la versión completa ↓

En qué consiste: CVE-2026-64561, denominada «Zapscape» por su descubridor, Hyunwoo Kim (@v4bel), es una vulnerabilidad de tipo «use-after-free» en la unidad de gestión de memoria en la sombra de Linux KVM x86. Dos rutas de fallo de página validan la raíz de la memoria sombra antes de recuperar las páginas de memoria sombra, en lugar de hacerlo después, por lo que KVM sigue creando asignaciones por debajo de una raíz que la recuperación ya ha invalidado. El resultado es una fuga completa del sistema invitado al host. El PoC publicado documenta una ruta para ejecutar código como root en el host, no solo un error de pánico que apaga todas las máquinas virtuales que comparten el mismo entorno. Ir a esta sección →

Posibles repercusiones: El investigador describe una vía que permite a un usuario invitado controlado por un atacante ejecutar código del núcleo del host, lo que supondría una fuga completa de una máquina virtual al host. La misma publicación describe otros dos resultados: un «panic» del host que interrumpe todas las cargas de trabajo que se ejecutan en la máquina afectada, y una vía independiente de escalada de privilegios locales que parte de una cuenta normal en el host donde /dev/kvm es de escritura global. Ir a esta sección →

Gravedad: Red Hat la clasifica como «Importante», con una puntuación base CVSS 3.1 de 7,0 bajo el código CWE-825. Para explotarla se necesitan privilegios de kernel de invitado, virtualización anidada y una configuración de host compatible. La propia descripción de Red Hat enmarca el impacto como inestabilidad y denegación de servicio en entornos virtualizados, lo que supone una interpretación considerablemente más moderada que la del investigador. Ir a esta sección →

¿Quiénes corren riesgo?: Servidores que ejecutan KVM con la virtualización anidada habilitada, en un núcleo que incluye el cambio introducido por la confirmación f95eec9bed76 en Linux 5.9 y aún no incluye la corrección del desarrollador original 2abd5287f083. Los sistemas AMD SVM que utilizan tablas de páginas anidadas son los más fácilmente accesibles. Los sistemas Intel requieren que se expongan al invitado de primer nivel tanto los recorridos de páginas EPT de cuatro niveles como los de cinco niveles, lo que limita esa vía a Ice Lake-SP y versiones posteriores. Ir a esta sección →

Lo que se ha comprobado: En nuestras pruebas, la demostración pública de concepto no ha dado lugar a una fuga de un sistema invitado al anfitrión en los núcleos creados con CloudLinux. No funciona en ellos sin modificaciones y, hasta ahora, las pruebas de reproducción internas solo han provocado un fallo del sistema invitado de primer nivel. Considera esta fuga como una posibilidad creíble, no como una vulneración demostrada en toda la flota. Ir a esta sección →

Qué hacer ahora: Empieza por averiguar si un host entra dentro del ámbito de aplicación.

cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null

A 1 o Y significa que el módulo KVM cargado permite la virtualización anidada, lo que sitúa al host dentro de la superficie de ataque potencial. Esto no demuestra por sí solo que sea explotable, ya que siguen siendo importantes el estado de los parches del núcleo, las capacidades de la CPU del host, el modelo de CPU virtual expuesto a L1 y si un invitado no de confianza puede crear L2.

La ausencia de salida suele significar que el módulo KVM correspondiente no está cargado en este momento, lo cual no es lo mismo que estar fuera del ámbito de aplicación; por lo tanto, comprueba cómo se utiliza realmente el host y si es posible cargar KVM más adelante. Lee el archivo en lugar de dar por hecho que nadie ha activado el anidamiento, ya que el KVM de origen tiene habilitado el parámetro de anidamiento por defecto tanto para Intel como para AMD desde Linux 4.20, y una distribución puede anular ese valor por defecto en cualquier sentido.

En los hosts que no necesiten virtualización anidada, desactívala, ya que así se elimina el requisito previo del que depende toda la cadena. Comprueba /dev/kvm los permisos como una medida de refuerzo independiente mientras estés allí.

KernelCare corrige esta vulnerabilidad en el kernel en ejecución sin necesidad de reiniciar el sistema ni la máquina virtual. Ya se han publicado los primeros parches que no requieren reinicio: Debian 13 se encuentra en el canal principal, y Ubuntu 24.04, Ubuntu 24.04 para AWS, Ubuntu 22.04 para AWS (kernels 6.8) y Proxmox VE 8 cuentan con compilaciones en el canal de pruebas que se espera que pasen al canal principal. Las familias restantes aún se encuentran en fase de compilación y revisión, y su disponibilidad se irá ampliando por kernel y canal a medida que se complete la validación. Aplica un kernel corregido del fabricante si ya existe uno para tu plataforma.

Hay dos descripciones de Zapscape circulando, y son muy diferentes entre sí. El investigador describe una cadena que culmina en la ejecución de código del núcleo del host desde el interior de un sistema invitado. Red Hat describe inestabilidad en entornos virtualizados. Ambos se refieren a la misma actualización del código.

La respuesta sincera se encuentra en un término medio, y los detalles que figuran a continuación explican por qué. Lo que se ha reproducido internamente tiene un alcance más limitado de lo que sugiere la divulgación. La prueba de concepto pública puede provocar el bloqueo del invitado L1 controlado por el atacante en algunos entornos, mientras que el investigador documenta una vía, que depende de la configuración, para llegar a la ejecución de código en el host. Vale la pena señalar claramente esa diferencia, y ninguna de las dos interpretaciones constituye un argumento para dejar sin parchear un límite de virtualización defectuoso.

La virtualización anidada permite que una máquina virtual ejecute a su vez otras máquinas virtuales. Un cliente de la nube podría utilizarla para ejecutar un hipervisor, probar software de infraestructura, gestionar un entorno de integración continua (CI) o habilitar funciones de Windows que dependan de Hyper-V.

Esto da lugar a una estructura de tres niveles:

• L0 es el host físico
• L1 es el sistema invitado controlado por el atacante
• L2 es una máquina virtual creada dentro de L1

Zapscape se aprovecha de la gestión de memoria que realiza L0 mientras atiende las actividades de L2. El atacante comienza con privilegios de root dentro de L1 y crea el sistema invitado anidado necesario para controlar la ruta KVM vulnerable.

Obtener acceso de root dentro de una máquina virtual en la nube no es algo inusual. Normalmente, los clientes controlan sus propios sistemas operativos invitados, y se supone que la barrera impide que ese acceso llegue al hipervisor. Zapscape se centra precisamente en esa barrera.

KVM utiliza tablas de páginas en la sombra para traducir los accesos a la memoria del sistema invitado en asignaciones del sistema anfitrión, y libera esas estructuras una vez que alcanza su cuota de páginas MMU activas.

Las rutas de fallo vulnerables, direct_page_fault() y FNAME(page_fault)(), llamado is_page_fault_stale() antes make_mmu_pages_available().

Ese orden es el error.

Recuperación en el interior make_mmu_pages_available() puede eliminar la raíz que KVM está utilizando en ese momento y marcarla como no válida. Dado que la comprobación de raíces obsoletas ya se ha ejecutado, KVM sigue creando asignaciones bajo una raíz que ya no es válida. Las páginas sombra secundarias heredan el rol de su página principal, por lo que heredan el estado no válido, y las páginas no válidas vuelven a aparecer en la lista de páginas activas de la MMU.

Esa es la confirmación invariante f95eec9bed76 añadido en Linux 5.9 para evitarlo. Una vez que falla, una limpieza recursiva posterior a través de mmu_page_zap_pte() funciona sin root_count protege y actúa sobre estructuras que ya han sido liberadas.

La prueba de concepto impulsa la secuencia cambiando los modos de memoria dentro de L1 para crear alias de páginas ocultas, mientras que la actividad de memoria procedente de L2 empuja a L0 hacia una recuperación basada en cuotas. A continuación, el investigador aprovecha la corrupción resultante para ejecutar código del núcleo del host.

El problema del orden en sí mismo se remonta a 2008. Pasó a ser relevante para la seguridad en Linux 5.9, cuando se introdujo la invariante que incumple. Nadie informó de un error en la versión 5.9. El núcleo simplemente empezó a depender de algo que nunca había sido cierto.

El investigador proporciona una prueba de concepto desde el lado del sistema invitado y documenta una ruta completa para la ejecución de código en el sistema anfitrión. Sin embargo, la explotabilidad depende en gran medida de la configuración. La vulnerabilidad afecta a AMD y se desarrolló para una configuración específica de Linux 7.1.3 en QEMU TCG, en lugar de en hardware de producción, por lo que para llegar a un sistema anfitrión real sería necesario reescribir las acciones del lado del sistema invitado y adaptarlas a la configuración del núcleo de destino.

Nuestras pruebas no han logrado reproducir la fuga completa en ningún núcleo compilado con CloudLinux. El exploit público no funciona en ellos sin modificaciones, y el resultado observado es un bloqueo del invitado L1, lo que supone una denegación de servicio para la propia máquina virtual del atacante, en lugar de un compromiso del host.

Merece la pena destacar Enterprise Linux 8 para cualquiera que lo pruebe por su cuenta. La prueba de concepto pública no produce ningún efecto en esta versión, ni siquiera un fallo del sistema, por lo que no puede servir como referencia de «antes y después» para esa familia. Comprueba los núcleos de EL8 con un conjunto de pruebas general de KVM en lugar de sacar conclusiones basándote en la ausencia de resultados.

Nada de eso demuestra que los núcleos afectados sean seguros. Significa que la vulnerabilidad debe describirse con precisión. Zapscape presenta una vía de escape creíble del espacio de invitado al de anfitrión, y el exploit público no constituye, por el momento, una vía de escape universal para todos los núcleos que contengan el código vulnerable.

La ruta de código vulnerable existe desde el cambio introducido en Linux 5.9 en la confirmación f95eec9bed76, con fecha del 8 de julio de 2020, a través de kernels que no han recibido la corrección 2abd5287f083, que aterrizó río arriba el 21 de julio de 2026.

La accesibilidad requiere además:

• KVM en uso
• Se debe habilitar la virtualización anidada
• Control a nivel del núcleo dentro del invitado L1
• Características de la CPU del host y de la CPU virtual compatibles con el ataque

En los servidores AMD que utilizan SVM y tablas de páginas anidadas, la vulnerabilidad no identifica ningún requisito previo adicional en cuanto a características de la CPU, más allá de los requisitos principales ya enumerados. Los sistemas Intel solo son vulnerables cuando las longitudes de recorrido de las tablas de páginas EPT de cuatro y cinco niveles están expuestas a la caché L1, lo que generalmente significa que se trata de Ice Lake-SP y versiones posteriores que incorporan dichas capacidades.

Familias de plataformas afectadas o potencialmente afectadas identificadas durante nuestro análisis:

• Enterprise Linux 10, AlmaLinux 10 y CloudLinux 10, en los que la adaptación de CentOS Stream 10 aún se encuentra en fase de borrador
• Kernels antiguos de Enterprise Linux 8 y 9 que no incluyen la corrección del proveedor, incluidas las variantes derivadas de EL8
• Debian 11, 12 y 13
• Ubuntu 22.04 y 24.04
• Oracle UEK7
• Proxmox VE 7 y VE 8

Ya corregido o fuera del ámbito de aplicación:

• Núcleos de RHEL 8 de 4.18.0-553.147.1.el8_10 a partir de entonces, enviado el 23 de julio de 2026
• Núcleos de RHEL 9 de 5.14.0-687.30.1.el9_8 en adelante, enviado el 22 de julio de 2026
• RHEL 6 y RHEL 7, incluido kernel-rt, que son anteriores al cambio introducido en Linux 5.9 que hizo que la vulnerabilidad tuviera implicaciones de seguridad
• Cualquier servidor que no ejecute KVM o que lo ejecute con la virtualización anidada desactivada

Las entradas de RHEL tienen una trampa. Red Hat publicó la corrección de forma discreta, junto con otras correcciones de vulnerabilidades, y su página pública de CVE siguió indicando que RHEL 8 y RHEL 9 seguían afectados tras la publicación de esas erratas. La información del registro de cambios es la indicación más fiable, y se sabe que el estado de la página puede cambiar en cuestión de horas, por lo que conviene volver a comprobar los datos actuales de Red Hat antes de informar de un estado de afectación a un cliente o a un auditor.

Esta precaución se aplica, en términos más generales. Los núcleos de los proveedores incorporan constantemente cambios individuales, por lo que el número de versión del desarrollador original no es indicativo del nivel de vulnerabilidad. Comprueba el aviso de seguridad y el estado del parche para el núcleo concreto que se está ejecutando.

Cómo mitigar Zapscape

Todos los requisitos previos para este error son elementos que se pueden eliminar. Se trata de tres medidas provisionales, no de sustitutos de la solución definitiva.

1. Desactiva la virtualización anidada. Es la opción más directa, ya que la cadena requiere que L1 cree y gestione su propia máquina virtual.

# /etc/modprobe.d/99-zapscape.conf
options kvm_amd nested=0
options kvm_intel nested=0

El parámetro del módulo se lee en el momento de la carga, por lo que aplicarlo implica detener todas las máquinas virtuales en ejecución y volver a cargarlas. kvm_amd o kvm_intel. En un servidor de producción, eso supone una pérdida de rendimiento o un reinicio, en lugar de un cambio en tiempo real.

Si la flota ejecuta máquinas virtuales normales de un solo nivel, aplícalo y sigue adelante, ya que nada en esa carga de trabajo requiere virtualización anidada. Si el host la ofrece de forma deliberada —piensa en inquilinos de hipervisores anidados, sistemas de integración continua (CI) que arrancan máquinas virtuales, entornos virtualizados de desarrollo y pruebas, o máquinas invitadas de Windows que utilizan VBS o Hyper-V—, déjala activada y da prioridad a la aplicación de parches. Evalúa el impacto en la carga de trabajo antes de intervenir en un host que no hayas configurado tú mismo.

2. Restringir el acceso a /dev/kvm. Esto no resuelve en absoluto un ataque procedente de un invitado ya existente. Cierra la ruta independiente por la que un usuario local normal del host accede directamente a KVM.

ls -l /dev/kvm

Si el dispositivo muestra el modo 0666, ajusta la configuración y concede acceso a los usuarios legítimos a través de la kvm grupo. Realiza ese cambio en una regla de udev en lugar de hacerlo con un simple chmod, ya que udev restablece el modo en el siguiente arranque o al producirse un evento del dispositivo.

3. Revisa la exposición del EPT de cinco niveles en Intel. Solo es relevante cuando ambas capacidades del EPT alcanzan el nivel L1.

grep -w ept_5level /proc/cpuinfo

Si no hay salida, significa que el host carece de la capacidad EPT de cinco niveles que requiere la ruta de Intel descrita. Si el indicador está presente, la siguiente pregunta es si tanto el EPT de cuatro niveles como el de cinco niveles llegan realmente al invitado L1 no fiable, ya que /proc/cpuinfo describe la CPU del host, en lugar de lo que transmite el modelo de CPU virtual. Cuando la virtualización anidada deba permanecer activada, evita los modelos de CPU que expongan el EPT de cinco niveles a sistemas invitados no fiables. En los sistemas Intel más recientes, desactivar la virtualización anidada sigue siendo la medida temporal más fiable.

Una vez que la protección esté activa, elimina la configuración temporal con sudo rm /etc/modprobe.d/99-zapscape.conf y volver a cargar el módulo durante la próxima ventana de mantenimiento.

La solución

La corrección en el código fuente ya se ha aplicado. 2abd5287f083, «KVM: x86: Comprobación de si existe una raíz no válida u obsoleta tras habilitar las páginas de la MMU».

El cambio es mínimo. Consiste en trasladar la comprobación de la raíz obsoleta a después de make_mmu_pages_available() en ambas rutas de fallo afectadas, con menos de una docena de líneas modificadas a lo largo de arch/x86/kvm/mmu/mmu.c y arch/x86/kvm/mmu/paging_tmpl.h. Ahora, KVM lleva a cabo primero cualquier proceso de recuperación y, a continuación, comprueba que la raíz siga siendo válida antes de continuar, lo que impide que el hipervisor cree asignaciones activas bajo una raíz que el proceso de recuperación ya haya invalidado.

No hay ninguna estructura de datos nueva, ni ningún estado persistente que supervisar. Eso es lo que lo hace adecuado para la aplicación de parches sin necesidad de reiniciar, aunque la adaptación en sí varía en función de cuánto se hayan desviado las rutas de error del núcleo de cada proveedor respecto a la rama principal.

Estado y despliegue de los parches de KernelCare

A fecha de 11 de agosto de 2026, ya se han publicado las primeras versiones:

Debian 13: canal principal
Ubuntu 24.04 Noble, Ubuntu 24.04 Noble para AWS, Ubuntu 22.04 Jammy para AWS, los núcleos 6.8 y Proxmox VE 8 se encuentran en el canal de pruebas

Se esperaba que las versiones de «test-feed» llegaran al canal principal ese mismo día, así que comprueba el estado del canal de tu kernel en lugar de dar por hecho que siguen siendo solo de prueba.

Situación familiar actual:

Todos los núcleos de Enterprise Linux 9 están cubiertos por parches en fase de revisión, salvo los núcleos más antiguos de la serie 70, que requieren una adaptación y cuyo tratamiento se ha aplazado para un trabajo aparte.

• Los parches de Ubuntu 24.04 ya están listos y se encuentran en fase de revisión
• Los parches de Debian 12 están en fase de revisión y a la espera de la validación del hardware
• Se han preparado parches para Enterprise Linux 8 y Ubuntu 22.04, cuya validación aún está pendiente
• Enterprise Linux 10 está en la lista de espera

El factor limitante en varias familias ha sido el hardware de pruebas de AMD, y no la complejidad de los parches. La disponibilidad variará según el núcleo hasta que se realicen las pruebas y se complete el despliegue.

Si estás deseando actualizar mientras un parche aún se encuentra en el canal de pruebas:

kcarectl --update --prefix test

Tras su implementación en el canal de producción, el parche se aplica en la siguiente ejecución programada o bajo demanda:

kcarectl --update

A continuación, comprueba qué es lo que realmente se ha cargado en el núcleo en ejecución:

kcarectl --patch-info | grep 'CVE-2026-64561'

La marca de tiempo de la compilación es la comprobación secundaria:

kcarectl --info | grep kpatch-build-time

Una versión con fecha del 6 de agosto de 2026 o posterior es un indicio útil, pero no una garantía de que ese kernel cubra ese CVE concreto. Si en la información del parche aún no aparece el CVE, confirma la cobertura para ese kernel concreto a través del servicio de atención al cliente, en lugar de dar por buena la fecha como prueba. En cualquier caso, compruébalo antes de eliminar una medida de mitigación temporal, no después.

Descubre cómo KernelCare corrige las vulnerabilidades críticas del núcleo sin necesidad de reiniciar el sistema →

Cronología

Referencias

• Hyunwoo Kim (@v4bel), informe sobre Zapscape enviado a oss-security
• Documento técnico y prueba de concepto de Zapscape, zapscape.io
• Corrección de Linux en la fase de desarrollo 2abd5287f083, «KVM: x86: Comprobación de si existe una raíz no válida u obsoleta tras habilitar las páginas de la MMU»
• Commit de Linux f95eec9bed76, «KVM: x86/mmu: No volver a incluir las SP no válidas en la lista de páginas activas»
• Aviso de Red Hat y ficha CVE correspondiente a CVE-2026-64561
• Solicitud de fusión 3068 para la adaptación a CentOS Stream 10, en borrador
• Avisos de seguridad aplicables a RHEL, AlmaLinux, CloudLinux, Debian, Ubuntu, Oracle y Proxmox