Cómo VsockDrop alcanza el nivel de root sin hipervisor y sin privilegios

La versión resumida

Ir a la versión completa ↓

Una vulnerabilidad del núcleo de Linux, a la que se le ha asignado una puntuación de 5,5, cuenta ahora con un exploit público que permite a un usuario local sin privilegios obtener privilegios de root. Esa es la parte de VsockDrop (CVE-2026-53365) por la que merece la pena actuar esta semana.

En qué consiste: VsockDrop es un exploit de escalada de privilegios locales (LPE) para CVE-2026-53365, un fallo en la ruta de envío «zerocopy» de virtio vsock del núcleo de Linux. Cuando un MSG_ZEROCOPY de gran tamaño envía fragmentos a través de varios búferes de socket, solo el último búfer contiene el objeto de finalización que busca la ruta de liberación. Todos los búferes anteriores contienen páginas de usuario fijadas, y el núcleo descarta entonces una referencia de página que nunca llegó a tomar.

Impacto potencial: Obtener privilegios de root desde una cuenta normal sin privilegios. El exploit reduce a cero el recuento de referencias de una página, consigue que esa página —que sigue fijada— se devuelva como caché de página para /usr/bin/su, reescribe la ruta del intérprete almacenada en su interior y ejecuta su. No se produce ninguna fuga de información ni se ejecuta código del núcleo en ningún punto de la cadena, lo cual explica en gran medida por qué funciona con tanta consistencia.

Gravedad: Tanto Red Hat como el NVD publican una puntuación CVSS base de 5,5 para el CVE-2026-53365, con un impacto elevado en la disponibilidad y sin impacto en la confidencialidad ni en la integridad; Red Hat lo clasifica como «moderado». El autor del exploit defiende una puntuación de 7,8. El vector describe el fallo en la contabilidad de recursos que documenta el mensaje de confirmación del desarrollador original. No tiene en cuenta la interacción con io_uring que convierte ese mismo objeto de finalización ausente en una página liberada mientras aún está en uso. Sea cual sea la puntuación final, el exploit público demuestra consecuencias para la confidencialidad y la integridad que el vector de 5,5 publicado actualmente no refleja.

Quiénes están expuestos: Ubuntu es el que requiere una atención más inmediata. Se ven afectados los núcleos de Linux a partir de la versión 6.7 que no hayan aplicado la corrección, y la accesibilidad depende de que un proceso sin privilegios pueda utilizar los búferes registrados en io_uring junto con un transporte vsock que permita zerocopy. Ambos están disponibles por defecto en Ubuntu 24.04 y en Ubuntu 22.04 con el núcleo 6.8 HWE. Enterprise Linux 9 y 10, incluidos RHEL, AlmaLinux, Rocky y CloudLinux, contienen el mismo código vulnerable, pero se distribuyen con kernel.io_uring_disabled establecido en 2, lo que bloquea la cadena de explotación demostrada.

Lo que se ha comprobado: El 18 de agosto de 2026, TuxCare logró reproducir un shell de root en Ubuntu 24.04 partiendo de una cuenta sin privilegios en la primera ejecución, sin realizar cambios en la configuración. En AlmaLinux 10.2, el mismo exploit se detuvo en la inicialización de io_uring tal y como venía de fábrica, y luego concedió acceso de root una vez que se volvió a habilitar explícitamente io_uring. Un intento en AlmaLinux 9.8 con io_uring vuelto a habilitar no consiguió acceso de root, lo cual no equivale a un resultado negativo claro.

Qué hacer ahora: Identifica el núcleo en ejecución y la política de io_uring; a continuación, comprueba si vsock está cargado.

uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'

Un valor de 2 significa que io_uring está desactivado en todo el sistema, incluido el usuario root, lo que bloquea la vía de explotación conocida para root sin eliminar el código vulnerable. Un valor de 0 significa que io_uring está disponible, que es la configuración predeterminada del desarrollador original y la que incluye Ubuntu. La salida del tercer comando confirma que hay un módulo relacionado con vsock cargado. La explotación pública puede utilizar vsock_loopback y VMADDR_CID_LOCAL, por lo que no es necesaria una máquina virtual.

Aplica un núcleo específico del proveedor, si existe. Debian 13 cuenta con uno. Canonical no ha proporcionado ninguno para las dos versiones de Ubuntu más relevantes. Cuando no es posible reiniciar el sistema de inmediato, KernelCare suele ser la solución habitual para disponer de un núcleo operativo que ya no presente el error; sin embargo, aún no se ha publicado ningún parche que no requiera reinicio para este CVE, por lo que las medidas de mitigación que se indican a continuación son las que deben aplicarse en estos sistemas mientras tanto.

Lo interesante de VsockDrop no es que exista otro CVE relacionado con el núcleo de Linux, sino la diferencia entre lo que describe el registro del CVE y lo que realmente hace el exploit público.

La vulnerabilidad CVE-2026-53365 se publicó el 13 de julio de 2026, dos meses después de que la corrección del proyecto original ya se hubiera implementado el 14 de mayo. La descripción oficial aborda el seguimiento de la finalización de «zerocopy» y las páginas fijadas que nunca se liberan, y tanto Red Hat como el NVD le otorgan una puntuación de 5,5, con un impacto limitado únicamente a la disponibilidad.

Entonces, la publicación del exploit cambió el panorama práctico. Demostró que el mismo fallo de contabilidad de referencias, combinado con búferes registrados con io_uring, libera una página que sigue fijada, la recupera como parte de un binario setuid y convierte a un usuario local normal en root.

Un fallo, dos consecuencias. El CVE recogió la más leve. Si una puntuación de 5,5 en un informe de vulnerabilidades es la razón por la que esto se ha eliminado de la lista de parches, debería volver a incluirse.

¿En qué consiste exactamente el CVE-2026-53365, también conocido como VsockDrop?

VsockDrop es un exploit de escalada de privilegios locales sin privilegios para la vulnerabilidad CVE-2026-53365 del núcleo de Linux, publicado en agosto de 2026 por Maher Azzouzi, a quien se le atribuye la autoría del informe que dio lugar a la corrección del desarrollador original. El nombre hace referencia al exploit y al informe técnico, y no a una vulnerabilidad independiente.

El código vulnerable se encuentra en la ruta de envío «zerocopy» de virtio vsock. AF_VSOCK suele estar asociado a la comunicación entre un sistema invitado y su hipervisor, por lo que lo natural es suponer que se trata de un problema de virtualización. Pero no es así. Linux expone un identificador de contexto vsock local a través del transporte vsock_loopback, VMADDR_CID_LOCAL, que es el CID 1, y la prueba de concepto utiliza ese punto final para comunicarse con el mismo sistema. No hay ningún hipervisor, ni sistema invitado, ni espacio de nombres de usuario, ni comprobación de capacidades entre una cuenta ordinaria y el código vulnerable.

Por lo tanto, el requisito previo no es tener control sobre un hipervisor, sino la capacidad de ejecutar un binario como un usuario local normal en un núcleo afectado en el que estén disponibles las funciones necesarias. En el alojamiento compartido, los sistemas de compilación multitenant, los ejecutores de CI y los servidores de enlace, esto describe a la mayoría de las cuentas del servidor.

La segunda pieza clave es io_uring. El exploit utiliza búferes registrados junto con el envío mediante «zerocopy», y esa interacción concreta es la que convierte un error de contabilidad de páginas en un desbordamiento de referencia y, a continuación, en privilegios de root.

El momento también es importante. La corrección se hizo pública el 14 de mayo de 2026, redactada por Stefano Garzarella, de Red Hat, y el ataque se produjo aproximadamente tres meses después. Nadie ha sido víctima de una emboscada, lo que también significa que todos los núcleos sin parchear han estado expuestos a una corrección publicada durante un trimestre entero.

Cómo funciona el exploit de root VsockDrop

Un envío MSG_ZEROCOPY no copia la carga útil. El núcleo bloquea las páginas de usuario, transmite a partir de ellas y, posteriormente, notifica al espacio de usuario a través de la cola de errores cuándo es seguro volver a utilizar esas páginas. El objeto que realiza el seguimiento de todo ello es el ubuf_info, normalmente denominado uarg.

En el modo «zerocopy», la ruta de envío de vsock limita cada búfer de socket a 64 KiB, por lo que cualquier dato de mayor tamaño se fragmenta. Antes de la corrección, el uarg solo se asociaba al último búfer del bucle. Los búferes anteriores seguían conteniendo páginas fijadas, sin el estado de finalización que el núcleo esperaba encontrar allí.

Esto, por sí solo, da lugar al problema de contabilidad de recursos que describe la CVE. Al espacio de usuario nunca se le indica que esas páginas están libres y, si el bucle de envío se interrumpe prematuramente, el uarg nunca se asigna.

Con los búferes registrados mediante io_uring, las consecuencias son diferentes. Esas páginas ya están fijadas a largo plazo, y la pila de red marca los fragmentos como referencias gestionadas, lo que significa que la ruta de liberación no debe tocarlas. La protección que garantiza esto se encuentra dentro de una comprobación para ver si el búfer tiene un uarg asociado. Si no hay uarg, la comprobación falla, nunca se consulta la protección y el bucle «unref» llama a put_page() en los fragmentos que nunca tomaron una referencia. El resultado es una reducción errónea de la referencia de página en cada envío.

Si se envía la misma carga útil a través de un iovec normal, no se produce nada de eso. En ese caso, io_uring toma las referencias adecuadas, los saldos contables cuadran y solo queda la fuga de memoria. Sin io_uring, no hay desbordamiento por debajo del rango.

A partir de ahí, las cuentas no son nada halagüeñas. El sesgo de fijación es 1024, una constante fija de la ABI, por lo que un número conocido de envíos agota una cantidad conocida del recuento de referencias en cualquier núcleo afectado. Se registra un búfer, se desasigna, se envían datos hasta que el recuento llega a cero, y el núcleo libera una página sobre la que io_uring aún mantiene una fijación. Al leer una página fría de /usr/bin/su, el asignador devuelve esa misma página física directamente como caché de página, ya que la lista de páginas libres funciona según el principio «último en entrar, primero en salir». El búfer aún registrado ahora hace referencia a esa caché de página; una escritura fija reescribe la ruta del intérprete ELF, y al ejecutar su, el núcleo carga un intérprete proporcionado por el atacante con credenciales de root ya aplicadas.

En esa cadena no se ejecuta código del núcleo. Se trata de una ruta hacia el usuario «root» que solo maneja datos, y si te resulta familiar, es normal. La vulnerabilidad «Copy Fail» (CVE-2026-31431) utilizó una idea similar a principios de 2026, corrompiendo la caché de páginas de un binario setuid para alcanzar el usuario «root» sin modificar el archivo subyacente. «VsockDrop» llega a un objetivo similar a través de un fallo del núcleo muy diferente.

Hay un detalle importante que debe tener en cuenta cualquiera que pruebe esto. El drenaje de referencia es determinista. La fase de recuperación de páginas es probabilística, y un intento fallido no puede repetirse en el mismo arranque. Por lo tanto, el exploit es fiable sin ser de un solo uso, y un único intento fallido no es prueba de que un kernel no se vea afectado.

¿Se ha confirmado que existe una vulnerabilidad explotable en VsockDrop?

Sí, en un núcleo de Ubuntu 24.04 afectado sin cambios en la configuración.

TuxCare reprodujo el exploit público en Ubuntu 24.04 el 18 de agosto de 2026, ejecutando un kernel de Azure 6.17. La ejecución se inició desde una cuenta sin privilegios y se obtuvo un shell de root al primer intento, sin realizar ningún ajuste ni reconfiguración. El único efecto colateral fue una entrada de «BUG: Bad page state» en dmesg. Esa imagen no incluye la corrección, y Canonical no ha publicado ninguna para ella.

AlmaLinux 10.2 se comportó de forma muy diferente. El exploit falló inmediatamente con el error «io_uring init failed», lo que se debe a que la configuración predeterminada del kernel, `io_uring_disabled = 2`, cumple exactamente su función. SELinux no es lo que lo detiene, por si esa fuera la suposición que se baraja aquí. No hubo denegaciones de AVC, y la ejecución siguió fallando con SELinux en modo permisivo. Con el sysctl establecido en 0, el siguiente intento concedió privilegios de root, con un dmesg limpio y sin errores «oops».

Que se haya «mitigado» tal y como se envió no es lo mismo que haya quedado «solucionado».

AlmaLinux 9.8 es el caso en el que hay que tener cuidado. Con io_uring reactivado, el exploit se ejecutó de principio a fin y luego falló sin conseguir privilegios de root. Eso no es un resultado negativo claro. Todas las condiciones previas del código para el desbordamiento por debajo del rango están presentes en el núcleo 5.14 incluido, el código de operación «zerocopy send» que necesita el exploit se ha retroportado a esa línea del núcleo, y Red Hat sigue indicando que RHEL 9 se ve afectado. La firma del fallo coincidió con un fallo conocido en un host al que ya se le había obtenido acceso root. Enterprise Linux 9 debe considerarse afectado en el código hasta que una prueba adecuada demuestre lo contrario.

Un intento fallido también deja rastros, que resultan más útiles de lo que parece. El exploit solo borra sus rastros si tiene éxito, por lo que, si falla, deja atrás los archivos /tmp/loader y /var/tmp/.s, y /var/tmp/.s tiene el atributo setuid de root. Se trata de un vector de escalada de privilegios locales dejado en el host por un intento que ni siquiera funcionó, y nadie suele buscar en /var/tmp. Elimínalo manualmente.

Una ejecución correcta interrumpe el proceso «su» hasta el reinicio, con el mensaje «no se puede ejecutar: no se ha encontrado el archivo requerido». Borrar las cachés no sirve de nada, ya que la página dañada sigue conteniendo una referencia, por lo que solo un reinicio la restaura. Se trata de una señal de detección sencilla y, en sí misma, de una interrupción visible para el usuario. La corrupción permanece en la caché de páginas y, en AlmaLinux, el comando «rpm -V util-linux-core» arrojó un resultado limpio posteriormente, por lo que el binario del disco no se vio afectado. En un sistema de archivos de «copia al escribir», esto podría no ser así, según la propia advertencia del autor del exploit.

¿Es Ubuntu 24.04 vulnerable a VsockDrop?

Sí. Las versiones del núcleo de Ubuntu 24.04 afectadas son vulnerables, y el exploit público de acceso a root se ha reproducido en Ubuntu 24.04 sin necesidad de realizar cambios en la configuración.

Actualmente, Canonical indica que CVE-2026-53365 afecta a los paquetes del núcleo Noble, lo que abarca las líneas 6.8 GA y 6.17 HWE, junto con las variantes de AWS, Azure, GCP y GKE. Ubuntu 22.04, que ejecuta el núcleo 6.8 HWE, también figura como vulnerable, y esa es la que cuenta con una base de usuarios más amplia de las dos.

Ubuntu es más importante de lo que sugiere la lista de paquetes afectados, ya que su configuración habitual de io_uring deja al descubierto el requisito previo para el exploit. Además, Canonical califica este CVE como de riesgo medio, por lo que no se ha tenido que emitir ningún aviso de seguridad al respecto.

Los núcleos más recientes basados en la versión 7.0 se están desarrollando por separado. Actualmente, Canonical indica que tanto Ubuntu 26.04 como la línea Ubuntu 24.04 HWE 7.0 son vulnerables y que se están preparando correcciones, por lo que conviene comprobar el estado exacto de los paquetes antes de dar por hecho que alguno de ellos ya se ha corregido.

¿Qué sistemas Linux se ven afectados?

Solo el panorama general es sencillo. El trabajo con vsock MSG_ZEROCOPY que introdujo este comportamiento se incorporó en Linux 6.7, y las correcciones estables se encuentran en las versiones 6.12.97, 6.18.34, 7.0.11 y 7.1. Los núcleos de las distribuciones deben evaluarse según los avisos de seguridad y los paquetes, ya que los proveedores retroportan características constantemente. RHEL 9 indica que utiliza un núcleo basado en la versión 5.14, numéricamente anterior a la 6.7, y Red Hat sigue señalando que RHEL 9 y RHEL 10 se ven afectados sin que se haya distribuido ninguna corrección, ya que la característica se retroportó a esa línea de núcleos.

Los backports trasladan tanto las características vulnerables como las correcciones a números de versión que no coinciden con los de la fuente original, por lo que debes considerar el comando «uname -r» como un identificador que hay que consultar, y no como una conclusión definitiva.

Lo que protege a Enterprise Linux 9 y 10 es esa configuración predeterminada, en lugar de un parche, y está compilada en el núcleo en lugar de incluirse como un archivo sysctl, por lo que cualquier sistema que arranque con ese núcleo la hereda, a menos que el espacio de usuario la modifique posteriormente. Las cargas de trabajo de bases de datos, proxies y contenedores la modifican deliberadamente, lo que hace que la vulnerabilidad en esos hosts sea real y no hipotética.

Cómo mitigar el VsockDrop

La cadena demostrada requiere búferes registrados con io_uring y un transporte vsock que permita el zerocopy. Si se elimina cualquiera de estos requisitos previos, la cadena deja de funcionar, lo cual es una situación mejor que la que suelen provocar la mayoría de los errores del núcleo. Ninguno de estos controles sustituye a la corrección del núcleo.

1. Mantén «io_uring» desactivado. En Enterprise Linux 9 y 10, el valor 2 ya es el estado predeterminado, por lo que se trata de un paso de verificación más que de un cambio. Evita modificarlo a menos que una carga de trabajo requiera realmente «io_uring».

Ubuntu es el caso contrario. Desactivar io_uring en este sistema elimina funcionalidades de las que pueden depender las aplicaciones en ejecución, como bases de datos, proxies y software de almacenamiento de alto rendimiento; por lo tanto, hay que considerarlo como un cambio operativo real con un alcance significativo. Además, es la única opción en tiempo de ejecución de la que disponen esos sistemas hasta que se publique una corrección. Cuando un servicio concreto necesite io_uring, un valor de 1 combinado con kernel.io_uring_group lo permite únicamente para los miembros de ese grupo, y cualquier valor distinto de 2 no debe interpretarse como equivalente a una desactivación total.

2. Elimina el transporte vsock allí donde no sea necesario. En un sistema «bare metal» sin usuarios de vsock, añadir el módulo a la lista negra suele transcurrir sin incidentes.

lsmod | grep -E 'vsock|vmw_vsock'

No lo apliques sin más a una máquina que, a su vez, sea un sistema invitado. Tanto el agente invitado de QEMU como VMware Tools utilizan transportes vsock, al igual que la virtualización anidada y cualquier sistema similar a Firecracker. Los módulos ya cargados requieren el comando «rmmod» o un reinicio para que la lista negra surta efecto, así que comprueba después de que el módulo haya desaparecido realmente.

Ninguna de estas medidas de control se ha probado frente a este exploit concreto, por lo que debes considerarlas como medidas previas para su eliminación y no como una neutralización verificada.

La solución para el problema de VsockDrop

La corrección en el código fuente es la confirmación ae38d9179190, «vsock/virtio: corrección de la finalización de zerocopy para envíos con varios SKB», y sigue el modelo que ya utiliza el protocolo TCP.

En lugar de crear el uarg a mitad del bucle de envío y asociarlo al último búfer que haya, la corrección lo asigna desde el principio, lo asocia a cada búfer mediante una referencia específica para cada uno de ellos y, a continuación, equilibra la referencia inicial. Cada vez que se completa una operación, se reduce el recuento; la notificación solo se activa una vez que se libera el último búfer, y un envío que falla sin transmitir nada cancela el uarg de forma limpia.

Con esto se resuelven ambas consecuencias a la vez. Ahora cada búfer contiene un uarg, por lo que el mecanismo de protección de fragmentos gestionados en la ruta de liberación se consulta tal y como siempre se pretendió, y dejan de producirse las caídas de referencias sueltas. El trabajo de retroportación varía en función de cuánto se haya desviado el kernel de cada proveedor de la rama principal.

La corrección está incluida en las versiones estables de origen 6.12.97, 6.18.34, 7.0.11 y 7.1. Los núcleos de los proveedores pueden incluir la misma corrección con números de versión totalmente diferentes.

Estado del parche sin necesidad de reinicio para CVE-2026-53365

A fecha de 18 de agosto de 2026, el equipo de KernelCare está trabajando en parches en tiempo real que no requieren reinicio para la mayoría de las distribuciones afectadas. Se espera que los primeros parches se implementen en un plazo de 48 horas.

Cuando se publican las actualizaciones, se instalan en la siguiente ejecución programada o bajo demanda.

kcarectl --update

A continuación, comprueba qué es lo que realmente contiene el núcleo que se está ejecutando.

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

Si no se obtiene ningún resultado, no interpretes esa ausencia como cobertura ni como una laguna. Confirma el kernel exacto con el servicio de asistencia antes de eliminar una medida de mitigación temporal, no después. La fecha y hora de compilación de un parche es una señal secundaria menos fiable y no debe considerarse una prueba de ningún CVE concreto.

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

Preguntas frecuentes sobre VsockDrop

¿Qué necesita un atacante para aprovechar la vulnerabilidad CVE-2026-53365? La capacidad de ejecutar un binario como usuario local sin privilegios en un kernel afectado, con io_uring disponible y un transporte vsock cargable. Sin hipervisor, sin máquina invitada, sin espacio de nombres de usuario y sin hardware especial.

¿Requiere VsockDrop una máquina virtual? No, y esa es la parte en la que se equivocan la mayoría de los resúmenes. El transporte vsock_loopback permite que un proceso sin privilegios se comunique consigo mismo a través del CID local, por lo que un host «bare-metal» sin ningún tipo de virtualización sigue siendo una opción viable.

¿Se ven afectados RHEL 9 y RHEL 10 por la vulnerabilidad VsockDrop? Red Hat señala que ambos están afectados, incluido kernel-rt, y aún no se ha publicado ninguna corrección. El exploit público no funciona tal y como se ha publicado, ya que esos núcleos rechazan io_uring de forma predeterminada, por lo que la vulnerabilidad solo se manifiesta cuando se ha modificado esa configuración predeterminada.

¿Se puede explotar CVE-2026-53365 de forma remota? No. Se necesita una cuenta local. Esto sigue afectando al alojamiento compartido, a los sistemas de compilación multitenant, a los ejecutores de CI y a cualquier servidor en el que un usuario de la aplicación pueda ejecutar un binario.

¿Cómo se puede saber si alguien lo ha intentado? Comprueba si existe /var/tmp/.s —que es lo que deja un intento fallido como binario setuid de root— y si existe /tmp/loader. Un comando «su» que falla indicando que falta un archivo necesario, junto con el mensaje «BUG: Bad page state» en dmesg, apunta a que se ha ejecutado con éxito en ese arranque.

¿Hay algún parche para CVE-2026-53365? Las correcciones del proyecto original se incluyen en las versiones 6.12.97, 6.18.34, 7.0.11 y 7.1, y Debian ha publicado correcciones para «trixie» y para el núcleo «bookworm» 6.12. Canonical no ha publicado ninguna para las versiones afectadas de Ubuntu, y, en el momento de redactar este artículo, no se ha publicado ningún parche que no requiera reinicio para este CVE.

Cronología de VsockDrop

Referencias

• Maher Azzouzi, demostración de concepto y informe técnico de VsockDrop, https://github.com/MaherAzzouzi/vsockdrop
• Corrección del proyecto original de Linux ae38d9179190, «vsock/virtio: corrección de la finalización de zerocopy para envíos con múltiples SKB», https://git.kernel.org/linus/ae38d9179190a956e2a87a69ef1dd6f451b51c4d
• Commit 581512a6dc93, «vsock/virtio: compatibilidad con el indicador MSG_ZEROCOPY», que introdujo el código afectado en Linux 6.7
• Commit 1cb36e252211, la corrección del recuento de páginas fijadas cuya revisión puso de manifiesto este defecto
• Red Hat CVE-2026-53365, https://access.redhat.com/security/cve/cve-2026-53365
• NVD CVE-2026-53365, https://nvd.nist.gov/vuln/detail/CVE-2026-53365
• Ubuntu CVE-2026-53365, https://ubuntu.com/security/CVE-2026-53365
• Debian CVE-2026-53365, https://security-tracker.debian.org/tracker/CVE-2026-53365