Nuevo fallo en el kernel de Linux permite a usuarios locales obtener root vía Open vSwitch

Un error de corrupción de memoria en la ruta de datos de Open vSwitch en el kernel de Linux permite a usuarios locales obtener privilegios de root. La vulnerabilidad, identificada como CVE-2026-64531, afecta a una amplia gama de distribuciones con configuraciones por defecto.

Un fallo de corrupción de memoria en la ruta de datos de Open vSwitch en el kernel de Linux permite a usuarios locales ordinarios obtener privilegios de root en una amplia gama de distribuciones con configuración predeterminada, y un código de prueba de concepto (PoC) público se ha lanzado con registros preconfigurados para aproximadamente 800 compilaciones del kernel.

La vulnerabilidad, rastreada como CVE-2026-64531 (puntuación CVSS: 7.8) y apodada OVSwrap por su descubridor, fue revelada por el investigador de seguridad Asim Manizada el 28 de julio de 2026.

Detalles técnicos del fallo

El error se encuentra en la ruta de datos del kernel, no en el demonio ovs-vswitchd del espacio de usuario. En un informe técnico, Manizada señaló que un atacante no requiere «ningún puente OVS existente, ningún ovs-vswitchd en ejecución, ni CAP_NET_ADMIN a nivel de host».

En los sistemas afectados donde la ruta de datos del kernel OVS está disponible y los espacios de usuario sin privilegios están habilitados, un usuario ordinario puede crear espacios de usuario y de red privados con `unshare -Urn`, obtener CAP_NET_ADMIN dentro de ese espacio y alcanzar la ruta vulnerable de instalación de flujos.

Si el módulo openvswitch está instalado pero no cargado, resolver su nombre de familia Netlink Genérico puede cargarlo automáticamente. Una salida vacía en `lsmod` no significa que un sistema sea seguro.

Origen del problema y versiones afectadas

La corrección upstream se envió en los árboles estables el 24 de julio. En los casos donde no esté disponible un kernel del fabricante parcheado y Open vSwitch no sea requerido, se deben bloquear las futuras cargas de módulos; si el módulo ya está residente, debe descargarse o reiniciarse el sistema.\n Manizada informó del problema a security@kernel.org y a los mantenedores de OVS el 19 de junio. Las primeras versiones upstream corregidas son Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 y 7.1.5. Las series de fin de vida (EOL) desde la 6.13 hasta la 6.17, la 6.19 y la 7.0 no recibirán correcciones estables upstream.

Esas cifras upstream no son suficientes por sí solas. Los kernels de las distribuciones incluyen retroportes y cambios downstream, por lo que el rastreador del fabricante es la fuente de información más fiable.

Open vSwitch almacena las acciones de flujo generadas como atributos Netlink cuyo campo nla_len tiene un ancho de 16 bits, limitando cualquier atributo anidado individual a 65.535 bytes. Esta asignación insegura había existido durante 13 años, pero un límite de 32 KiB en el flujo de acciones generado mantenía una acción anidada por debajo del punto de desbordamiento.\n Un cambio en marzo de 2025 eliminó ese límite porque producía fallos impredecibles, incluidos en despliegues grandes de OpenStack, y expuso el antiguo error de truncamiento. El hilo de revisión del commit que habilitó esto discutió la fiabilidad y los fallos visibles para el usuario, pero no abordó la consecuencia de seguridad de eliminar la protección.

Explotación activa y mecanismos de ataque

Un atacante envía una acción CLONE empaquetada con cientos de sub-acciones conntrack. En x86-64, el kernel expande cada una a 164 bytes, empujando la acción anidada generada más allá de los 65.535 bytes. Cuando OVS escribe el resultado en el campo de longitud de 16 bits, el valor se desborda (wrap).

Posteriormente, el código confía en esa longitud y reanuda el análisis desde el interior de los datos conntrack controlados por el atacante, donde esperan acciones OVS falsificadas. Debido a que el punto de llegada es determinista dentro del mismo búfer contiguo, no se requiere una preparación de memoria (heap grooming).

Manizada describió el resultado como una vulnerabilidad de corrupción de memoria con una «fiabilidad de nivel de error lógico».

El exploit encadena tres primitivas derivadas del desbordamiento: una filtración de puntero del kernel a través de una acción OUTPUT falsa, una lectura arbitraria del kernel a través de una acción SET de túnel falsificada y un decremento dirigido mediante la desactivación de un puntero tun_dst falsificado. Utiliza estas primitivos para encontrar las credenciales de un proceso del host y, en kernels modernos, reducir fsuid y fsgid a cero.

El código de prueba de concepto (PoC) publicado es explícitamente destructivo. También requiere que estén instalados el soporte OVS conntrack, el ayudante conntrack de FTP y sudo. En caso de éxito, corrompe una credencial del kernel en ejecución, modifica /etc/sudoers.d o /etc/sudoers, abre una shell de root y deja los procesos y el estado de OVS intactos para evitar un cierre inseguro. El repositorio del PoC incluye registros para aproximadamente 800 compilaciones exactas de kernel x86-64 e intenta la derivación dinámica desde símbolos o BTF para las compilaciones no cubiertas.

La matriz de pruebas no exhaustiva de Manizada encontró explotabilidad en configuraciones por defecto en 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.

En los sistemas probados con Ubuntu 24.04, AppArmor bloqueó la creación directa de namespaces, pero el fallback aa-exec -p trinity del PoC restauró la accesibilidad. El sistema estándar Ubuntu 26.04 bloqueó la ruta para usuarios ordinarios; desactivar su restricción de AppArmor sobre namespaces de usuario hizo que los sistemas probados fueran explotables.\n Los sistemas probados Amazon Linux 2, Debian 11, Rocky Linux 8 y Ubuntu 20.04 conservaron rutas de código antiguas y no fueron explotables a través de esta vía.

Recomendaciones de mitigación

Instale un kernel del fabricante parcheado donde esté disponible. En los casos en que Open vSwitch no sea requerido, el paso intermedio más rápido es un bloqueo de módulo:

`echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf`

Esta anulación bloquea los intentos futuros de carga del módulo; un módulo que ya resida en memoria aún debe ser eliminado o limpiado mediante un reinicio.

Deshabilitar los namespaces de usuario sin privilegios cierra la ruta para el usuario local ordinario, pero no bloquea un contenedor u otro proceso que ya posea CAP_NET_ADMIN sobre un namespace de red controlado por un atacante. Manizada describió la dirección hacia contenedores como teóricamente alcanzable, aunque no la demostró en el PoC publicado. El repositorio del PoC también incluye una protección BPF de emergencia para entornos que deban mantener activos tanto OVS como los namespaces.\n El riesgo es especialmente agudo donde múltiples usuarios o cargas de trabajo no confiables comparten un host. Como indicó el aviso de CloudLinux, el usuario local en ese escenario puede ser un atacante que ya haya comprometido un sitio a través de una falla no relacionada, y OVSwrap es lo que convierte ese problema de una sola cuenta en un problema de todo el servidor.

Fuente:
https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html

Contenido traducido al español con fines informativos, cualquier cambio en la publicación original no será reflejada en esta entrada, favor referirse a la fuente para obtener el acceso a cualquier actualización del contenido. Para la traducción se utilizó un LLM, al ser una traducción automática puede contener errores gramaticales o de otro tipo, me pueden enviar un mensaje.