ITScape: El primer exploit de escape en KVM/arm64 pone en jaque a la nube ARM

El error se encuentra en la función vgic_its_invalidate_cache(), que recorre la caché de traducción de la ITS con xa_for_each() y llama a vgic_put_irq() sobre el puntero iterado, en lugar de hacerlo sobre el valor devuelto de forma segura por xa_erase(). Múltiples contextos pueden entrar en esta función bajo diferentes candados (locks), por lo que la condición de carrera es completamente alcanzable desde un invitado .

Por qué es importante: El primer escape de invitado a anfitrión en KVM/arm64

Aunque los escapes de invitado a anfitrión son poco comunes, representan la clase más peligrosa de errores en un hipervisor porque destruyen la barrera de aislamiento en la que se basa la computación en la nube. Los escapes de KVM públicos anteriores apuntaban a x86, usualmente a través de QEMU o código específico de AMD . ITScape es el primer exploit funcional que demuestra una fuga desde una VM invitada arm64 sin privilegios a través del propio código de KVM dentro del kernel, sin requerir vulnerabilidades en el emulador de espacio de usuario .

Para los proveedores de nube que operan infraestructura multi-inquilino con procesadores Graviton de AWS, Ampere Altra o cualquier anfitrión KVM en arm64, un invitado malicioso puede:

• Leer y escribir en la memoria arbitraria del kernel del anfitrión.
• Escalar privilegios para ejecutar código en el nivel más privilegiado del sistema anfitrión.
• Realizar movimientos laterales hacia otras VMs, contenedores o la red del anfitrión.

La mayoría de los equipos de seguridad han calificado la vulnerabilidad por encima de 9.0 en la escala CVSS, reflejando su severidad crítica .

Causa raíz en detalle

El código vulnerable se encuentra en la ruta de invalidación de la caché de traducción de LPIs. Cuando el kernel necesita limpiar las entradas de la caché, itera a través del XArray con xa_for_each() y llama a vgic_put_irq() para liberar el contador de referencias de cada entrada. El problema es que xa_for_each() puede devolver entradas que ya han sido borradas por una operación concurrente, como un comando DISCARD ITS emitido desde otra vCPU. El bucle de invalidación aún intenta liberar la referencia de esa entrada ya eliminada, causando una doble liberación y, en última instancia, un use-after-free .

Una vulnerabilidad anterior en el mismo código, CVE-2024-26598, había solucionado parcialmente un UAF en la ruta de acierto de caché de traducción de LPIs elevando el contador de referencias dentro de vgic_its_check_cache() antes de liberar el candado. Esa corrección no cubrió la ruta de invalidación, dejando la condición de carrera explotable a través de una secuencia diferente .

El Parche

La solución oficial, integrada en el kernel principal de Linux, modifica vgic_its_invalidate_cache() para que vgic_put_irq() sea llamada únicamente sobre el valor devuelto por xa_erase(), no sobre cada entrada que toca el iterador. El mensaje del commit oficial describe el cambio como: "KVM: arm64: vgic-its: Liberar la referencia de la caché solo para la entrada borrada" .

Dado que xa_erase() elimina atómicamente y devuelve la entrada antigua — o devuelve NULL si la entrada ya no existía — la solución asegura que el contador de referencias se decremente exactamente una vez, eliminando la ventana de doble liberación. El parche se incorporó al kernel principal a principios de junio de 2026 y se integró rápidamente en las series estables del kernel 6.x alrededor del 8 al 10 de junio de 2026 . Distribuciones importantes como Red Hat, SUSE y Debian han publicado correcciones adaptadas para sus ramas de kernel con soporte .

Versiones Afectadas

• Introducción del fallo: Finales de abril de 2024, cuando la caché de traducción de LPIs se añadió a KVM/arm64 .
• Ventana de vulnerabilidad: Kernels compilados aproximadamente desde abril de 2024 hasta principios de junio de 2026 .
• Corregido: Parche integrado en el kernel principal a principios de junio de 2026; incluido en los kernels estables 6.x más recientes y en los parches retroadaptados (backports) de las distribuciones .

Prueba de Concepto (PoC)

Hyunwoo Kim publicó un exploit funcional en GitHub alrededor del 9 o 10 de junio de 2026. El repositorio incluye el código fuente completo, instrucciones de reproducción paso a paso y una descripción técnica de la técnica de explotación . El exploit activa la carrera coordinando hilos de vCPU que emiten simultáneamente comandos DISCARD y búsquedas en la caché de traducción de LPIs, logrando el use-after-free para ejecutar código en el anfitrión.

La disponibilidad pública de una PoC confiable significa que los escáneres de explotación automatizados y los actores maliciosos reales pueden utilizar la vulnerabilidad con un esfuerzo mínimo, acortando el tiempo entre la divulgación y los ataques activos.

Mitigación Urgente para Operadores de Nube ARM64

Si opera infraestructura KVM en arm64 de tipo multi-inquilino — como instancias AWS Graviton, servidores Ampere Altra o cualquier plataforma similar — considere esto como un ciclo de parcheo de emergencia inmediata.

1. Aplique el parche al kernel del anfitrión ahora. Instale el kernel estable más reciente que contenga la solución de principios de junio de 2026, o el paquete retroadaptado de su distribución .
2. Deshabilite el vGIC-ITS en el kernel para invitados no confiables si no puede parchear de inmediato. Con QEMU, se puede forzar la emulación de la ITS de GICv3 hacia el espacio de usuario, o no exponer las capacidades de la ITS de GICv3 a los inquilinos no confiables .
3. No dependa del endurecimiento del invitado. Esta es una vulnerabilidad a nivel de hipervisor; no existe una solución temporal dentro de la VM .
4. Audite su flota en busca de kernels vulnerables. Cualquier host KVM en arm64 que ejecute un kernel compilado entre abril de 2024 y principios de junio de 2026 con el vGIC-ITS en uso está en riesgo .
5. Monitorice indicadores de explotación. Con el código de la PoC disponible públicamente, el escaneo activo y los intentos de compromiso son altamente probables .