Ilustración editorial generada con IA por Defensops. No es una fotografía del incidente ni de los equipos afectados. Representa Ilustración conceptual de una página de memoria del host accesible desde KVM ARM64.

Síntesis y análisis propios a partir de la cobertura de The Hacker News; las afirmaciones del medio se atribuyen a su fuente.

Qué se ha confirmado

The Hacker News describe CVE-2026-89775 en el código KVM para ARM64: una máquina virtual invitada puede leer y escribir memoria del kernel del host cuando está habilitada la virtualización anidada.

La condición de virtualización anidada requiere un modo experimental de arranque y hardware Armv8.4 con FEAT_NV2; en ARM64 está desactivada por defecto.

Según la explicación técnica recogida, un cálculo de tamaño igual a cero omite la invalidación de TLB y deja una página liberada del host mapeada con permisos de escritura para el invitado.

El investigador Hyunwoo Kim sostiene que el fallo permite escapar de la máquina virtual y ejecutar código en el host, pero la publicación no identifica código de explotación público ni ataques observados.

La fuente enumera correcciones en Linux 6.18.51, 7.2.5 y 7.3-rc1; cada distribución las incorpora según su propio calendario.

The Hacker News señala una segunda vía: en sistemas donde cualquier usuario puede abrir /dev/kvm, un usuario local podría crear un invitado y aprovechar el fallo para elevar privilegios.

Análisis de Defensops

El impacto potencial rompe el aislamiento entre invitado y host, una frontera crítica en plataformas de virtualización compartidas. Sin embargo, el alcance real es más estrecho que el de todos los servidores ARM64: además de una versión afectada, el host debe reunir la capacidad de hardware y tener activado el modo anidado. La clasificación de un inventario debe comprobar esas condiciones, no deducir exposición por el nombre del procesador.

La vía desde una máquina virtual y la posible elevación de un usuario local comparten el mismo requisito de configuración, pero cambian el punto de partida del atacante. El permiso de acceso a /dev/kvm importa para la segunda. Ninguna de las dos debe presentarse como explotación observada: el investigador demuestra viabilidad técnica y la fuente dice que no hay indicios de uso real.

La versión principal del kernel no basta para decidir si un sistema está corregido. Los proveedores distribuyen parches por ramas propias y hay discrepancia histórica sobre cuándo empezó el comportamiento explotable: el registro del kernel sitúa el código desde 6.16 y un mantenedor lo acota a 6.17. Conviene utilizar el aviso de la distribución instalada y registrar la revisión exacta del paquete.

Prioridades de revisión

Inventariar hosts KVM ARM64 y comprobar qué equipos tienen la virtualización anidada activada, hardware FEAT_NV2 y versiones afectadas según su distribución.

En los hosts que cumplan esas condiciones, verificar el estado del parche del proveedor e instalar la actualización corregida disponible, con una ventana de reinicio que garantice cargar el nuevo kernel.

Si la virtualización anidada no es necesaria, planificar su desactivación y comprobar tras el arranque que la función dejó de estar disponible para los invitados.

Revisar quién puede abrir /dev/kvm en hosts afectados y limitar ese acceso a los usuarios y servicios que lo necesitan mientras se corrige el sistema.

Documentar la versión efectiva del kernel y la configuración de cada host para distinguir los sistemas expuestos de los que solo comparten arquitectura.

Qué no se ha confirmado

No se han publicado pruebas de explotación en ataques reales ni código de explotación público en la cobertura consultada.

La rama mínima con el comportamiento explotable difiere entre el registro del kernel y la valoración del mantenedor.

El estado de los paquetes corregidos puede haber cambiado en cada distribución desde la fecha de la fuente.

Fuente

The Hacker News. Fecha indicada: 2026-09-22.