Una vulnerabilidad en el subsistema vhost del kernel de Linux permite a un usuario local leer y escribir memoria del kernel a voluntad y convertirse en root en versiones que abarcan casi una década. En una configuración de virtualización, permite que una máquina virtual no confiable escriba en la memoria del host y secuestre el programa que ejecuta la máquina virtual.
El fallo está registrado como CVE-2026-74580 y ha sido bautizado como Vghost. Tencent Zhuque Lab, que lo descubrió, publicó un parche el 3 de agosto y un análisis completo el 12 de octubre con demostraciones funcionales de ambos ataques. No hay señales públicas de que haya sido explotado.
vhost es la parte del kernel de Linux que acelera la red y otras operaciones de entrada/salida para máquinas virtuales y contenedores. Un usuario local accede a él abriendo un nodo de dispositivo, normalmente /dev/vhost-net o /dev/vhost-vsock.
En el host, el fallo proporciona a un usuario sin privilegios una forma fiable de leer y escribir cualquier dirección del kernel, eludir KASLR y escalar a root. El ataque es determinista: no requiere manipulación de memoria ni sincronización afortunada.
El segundo ataque es más limitado. Cuando el dispositivo virtio de una máquina virtual se coloca detrás de una IOMMU virtual con iommu_platform activado, y vhost se ejecuta en modo device-IOTLB, un invitado no confiable puede desencadenar el mismo fallo y hacer que el kernel del host escriba fuera de los límites en el proceso QEMU del host. Desde allí, un invitado puede sobrescribir un puntero a función en QEMU y tomar el control de dónde se ejecuta el proceso del host a continuación, o hacer que se bloquee.
Cómo funciona
vhost mantiene una pequeña caché de las asignaciones de memoria detrás de cada anillo virtual y las colas compartidas que utiliza para mover datos. Un acierto de caché se trata como prueba de que la región ya fue verificada. La caché se borra cuando la asignación se actualiza o invalida y cuando la cola se reinicia, pero no cuando los comandos VHOST_SET_VRING_ADDR o VHOST_SET_VRING_NUM cambian las direcciones o el tamaño del anillo mientras la cola está activa.
Con una IOTLB de dispositivo adjunta, esos comandos aceptan las nuevas direcciones sin verificarlas, dejando esa comprobación para más tarde. Una vez que la caché se llena, la verificación posterior nunca se ejecuta y vhost continúa traduciendo nuevas direcciones usando la asignación antigua. El kernel luego copia datos hacia o desde ese puntero sin comprobar los límites, por lo que una escritura en el anillo usado o una lectura de un descriptor cae fuera de la región mapeada. Eso otorga al atacante lectura y escritura en el kernel.
El fallo permaneció en el código durante unos nueve años porque fueron necesarios dos cambios razonables para crearlo. Un cambio de 2017 (Linux 4.11) añadió la caché y su atajo. Un cambio de 2020 (Linux 5.9) movió la verificación de direcciones fuera del comando y a un paso posterior, eliminando la comprobación que de otro modo habría detectado la traducción obsoleta.
Quién está afectado y qué hacer
El fallo afecta a los kernels de Linux desde la versión 4.11 hasta la 7.2-rc4. Tencent reprodujo la cadena completa de usuario local a root en cinco kernels de distribución: Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0 y Oracle Linux 10.2. En Ubuntu, el nodo del dispositivo estaba limitado al grupo kvm, por lo que el punto de partida era un miembro de ese grupo en lugar de cualquier usuario.
En las otras cuatro imágenes probadas, el nodo era legible por todos con modo 0666, por lo que cualquier usuario local podía acceder a él.
El parche (commit de845981da67) borra la caché cada vez que se reconfigura el anillo. Instale un kernel que lo contenga y reinicie. Las primeras versiones estables upstream corregidas se enumeran a continuación; los proveedores también pueden aplicar el parche sin cambiar su número de versión.
Red Hat, Amazon Linux y Oracle Linux ya han publicado correcciones. Ubuntu ha corregido la 22.04 y, a 13 de octubre, todavía indica que sus kernels 24.04 y 26.04 están en proceso.
Hasta que haya un kernel corregido instalado, restrinja el acceso a los nodos de dispositivo vhost. Elimine el acceso global a /dev/vhost-net y /dev/vhost-vsock, limite el grupo propietario a servicios de virtualización de confianza y trate la pertenencia a ese grupo como un privilegio mientras el kernel vulnerable esté en ejecución.
No hay solución alternativa provisional para el escape de invitado a host; para esa vía, el kernel parcheado es el único remedio.
La gravedad y el hallazgo por IA
El fallo está calificado como alto, no crítico, y los evaluadores discrepan sobre su gravedad. El equipo CVE de kernel.org le asigna 8.8 y marca su alcance como cambiado, porque la escritura de invitado a host llega a la memoria del proceso QEMU del host y cruza la frontera entre un invitado y su host.
Red Hat lo puntúa con 7.3 y marca el alcance como sin cambios, tratando el impacto como si permaneciera dentro del límite de confianza del propio host; también califica el impacto en la integridad como menor. Amazon lo puntuó con 7.8 y Oracle con 7.3.
El error se encontró con la ayuda de Corvus AI, un sistema multiagente creado por Tencent para la investigación de vulnerabilidades del kernel. El parche upstream le acredita con una línea Assisted-by, y Tencent afirma que la cadena de análisis encontró el fallo.
Se trata de investigación asistida por máquina, no de un ataque ejecutado por IA. Es el mismo equipo y la misma cadena de análisis detrás de un fallo del kernel SCTP de 18 años de antigüedad revelado en agosto, que también permitía alcanzar root y, en pruebas, escapaba de un contenedor.
Deja una respuesta