El equipo de seguridad ha advertido sobre una nueva vulnerabilidad en OVSwrap en Linux: una falla de corrupción de memoria en el datapath del kernel de Open vSwitch que, bajo configuraciones por defecto en varias distribuciones, puede abrir la puerta a privilegios de root para usuarios locales. Lo relevante es que no se trata de un problema típico “en espacio de usuario”, sino en el camino del kernel que procesa flujos.
El fallo está identificado como CVE-2026-64531, tiene una puntuación CVSS de 7.8 y su nombre en clave es OVSwrap. El investigador Asim Manizada lo divulgó el 28 de julio de 2026, y la comunidad ya dispone de una prueba de concepto pública con parámetros preconstruidos para múltiples builds del kernel.
Qué es OVSwrap en Linux y por qué es peligroso
La vulnerabilidad afecta al datapath del kernel de Open vSwitch, no al demonio ovs-vswitchd que corre en espacio de usuario. En el análisis técnico del descubridor se indica que un atacante no necesita: un puente OVS existente, ovs-vswitchd en ejecución ni el privilegio CAP_NET_ADMIN a nivel de host.
En sistemas afectados donde el datapath del kernel está disponible y las user namespaces sin privilegios están habilitadas, un usuario “normal” puede preparar un entorno con espacios de nombres privados usando unshare -Urn, obtener CAP_NET_ADMIN dentro de ese namespace y alcanzar la ruta vulnerable de instalación de flujos.
Este matiz es importante: aunque el módulo de Open vSwitch no esté cargado, el proceso de resolución de la familia Generic Netlink puede terminar cargándolo automáticamente. Por eso, tener una salida vacía de lsmod no debe interpretarse como señal de seguridad.
Mecanismo técnico: corrupción por “wraparound” de longitudes
En el corazón del problema hay una forma de “envoltura” (wraparound) ligada a cómo Open vSwitch guarda acciones generadas para los flujos mediante atributos Netlink. El campo nla_len tiene un ancho de 16 bits, lo que limita el tamaño máximo de un atributo anidado a 65.535 bytes.
Según el investigador, el error inseguro existía desde hace años, pero un límite adicional de 32 KiB en el flujo total generado mantenía a los atributos anidados por debajo del punto de envoltura. En marzo de 2025, se eliminó ese límite porque podía causar fallos impredecibles (se mencionan impactos incluso en despliegues grandes de OpenStack). Al quitar la protección, reapareció el comportamiento de truncamiento/ajuste antiguo.
El ataque consiste en enviar una acción CLONE que contiene cientos de sub-acciones de conntrack. En arquitecturas x86_64, el kernel expande cada sub-acción a 164 bytes, empujando el bloque generado más allá del máximo permitido. Cuando Open vSwitch escribe el resultado en el campo de 16 bits, el valor se desborda.
Después, el código posterior confía en esa longitud truncada y reanuda el análisis desde un punto que termina dentro de datos controlados por el atacante. Como el “punto de aterrizaje” es determinista dentro del mismo búfer contiguo, no se requiere “heap grooming” (manipulación compleja del heap) para que el flujo de ejecución sea alcanzable.
Cadena de explotación: de la lectura a la ganancia de credenciales
El descubridor describe el resultado como una vulnerabilidad de corruptión de memoria con fiabilidad de nivel lógico. El exploit encadena varios “primitives” derivados del wraparound:
- Una fuga de puntero del kernel mediante una acción OUTPUT falsificada.
- Una lectura arbitraria del kernel usando una acción SET para un túnel forjado.
- Un decremento dirigido al desmontar estructuras forjadas relacionadas con un puntero tun_dst.
Con esos pasos, el PoC localiza las credenciales de un proceso del host y, en kernels modernos, realiza decrementos que terminan reduciendo fsuid y fsgid hasta cero.
La prueba de concepto publicada es explícitamente destructiva. Además, requiere soportes concretos: soporte de conntrack en Open vSwitch, el helper FTP conntrack y la presencia de sudo.
Cuando el ataque tiene éxito, corrompe credenciales del kernel en un sistema activo, puede modificar archivos como /etc/sudoers.d o /etc/sudoers, abre una shell root y deja estados en el sistema. Se indica que el PoC intenta reducir riesgos de “teardown” inseguro, conservando parte del estado de OVS.
Impacto práctico: qué sistemas se vieron afectados
La publicación incluye una matriz de pruebas no exhaustiva donde el exploit funcionó con configuraciones por defecto en diferentes distribuciones. Entre las mencionadas están AlmaLinux 9 y 10, Alpine 3.22 a 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 y 10, Debian 12 y 13, Fedora 42 a 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 y 10 y Ubuntu 22.04.
También hay resultados relevantes en Ubuntu: en Ubuntu 24.04 la protección AppArmor bloqueó la creación directa de namespaces; sin embargo, el PoC incluye un camino alternativo con aa-exec -p trinity que restablece la alcanzabilidad. En Ubuntu 26.04, el exploit bloqueó la ruta “de usuario ordinario”, pero al desactivar la restricción de AppArmor sobre user namespaces sí se hizo explotable en las pruebas realizadas.
En contraste, algunas versiones probadas no permitieron la explotación por la ruta indicada: por ejemplo Amazon Linux 2, Debian 11, Rocky Linux 8 y Ubuntu 20.04 conservaban rutas de código anteriores.
Fix y versiones: qué se sabe del parche
El fix se incorporó a árboles stable el 24 de julio. A nivel upstream, el artículo menciona primeras versiones corregidas como: Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 y 7.1.5.
Además, se señala que ramas con fin de vida como 6.13 a 6.17, 6.19 y 7.0 no recibirán correcciones stable upstream.
Ahora bien, los números upstream por sí solos no garantizan la seguridad en tu sistema. Las distribuciones suelen incorporar backports y cambios downstream. Por eso, el consejo es usar como referencia el tracker del proveedor o el estado de parcheo de tu kernel, no únicamente la versión “base”.
Mitigaciones inmediatas si aún no puedes actualizar
Si ya conoces que Open vSwitch está presente pero aún no tienes un kernel parcheado, hay medidas de contención. La más rápida, cuando Open vSwitch no es requerido, consiste en impedir la carga futura del módulo.
Una forma recomendada es crear un archivo de configuración de modprobe con un “bloqueo” del módulo:
echo ‘install openvswitch /bin/false’ > /etc/modprobe.d/ovswrap.conf
Ten en cuenta que esto bloquea cargas futuras. Si el módulo ya está residente en memoria, será necesario descargarlo o realizar un reboot para limpiar el estado actual.
Otra mitigación mencionada es deshabilitar unprivileged user namespaces. Esto cierra la ruta local típica descrita para un usuario ordinario, aunque no bloquea automáticamente un escenario donde un contenedor o proceso ya tiene CAP_NET_ADMIN sobre un network namespace controlado por el atacante. El investigador comenta que esa dirección es “teóricamente alcanzable”, pero no la demostró en la PoC liberada.
Por qué el riesgo se amplifica en entornos multiusuario
El impacto real es especialmente preocupante cuando múltiples usuarios o cargas no confiables comparten un mismo host. La razón es directa: un fallo que permite escalar a root desde una cuenta comprometida convierte un incidente “de una sola cuenta” en un compromiso del servidor completo.
En otras palabras, si un atacante ya logró ejecutar algo en un contexto no privilegiado (mediante otra vulnerabilidad o una mala configuración previa), OVSwrap en Linux puede actuar como el escalón final para tomar control total.
Recomendaciones de acción para equipos de TI
Si gestionas servidores Linux con Open vSwitch o con kernels que podrían incluir el datapath afectado, prioriza este orden de trabajo:
- Verifica estado de parches del kernel con el tracker de tu distribución (no solo upstream).
- Revisa si Open vSwitch está instalado y si existe disponibilidad del datapath del kernel.
- Aplica mitigación por módulo si no necesitas Open vSwitch: bloquea futuras cargas y fuerza limpieza si el módulo ya está presente.
- Considera deshabilitar user namespaces no confiables como contención temporal, evaluando el impacto en tus plataformas.
Con esto, reduces de forma significativa la probabilidad de que un usuario local (en el conjunto correcto de condiciones) alcance la ruta vulnerable.
Conclusión
OVSwrap en Linux combina una corrupción de memoria en el datapath del kernel de Open vSwitch con condiciones que pueden estar presentes en configuraciones por defecto. El resultado, asociado a CVE-2026-64531, permite escalada de privilegios a root desde usuarios locales en ciertos entornos y ya existe una PoC pública para múltiples builds.
La clave está en actuar: actualiza a kernels corregidos según tu proveedor, y si no es posible de inmediato, aplica contención bloqueando carga del módulo y restringiendo user namespaces no confiables. En entornos compartidos, estas medidas no deberían esperar.
Fuente: https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html
