Use-After-Free en TCP: CVE-2026-98432 / CVSS 9.8

Artículo original ↗ Discusión en Hacker News ↗

Una vulnerabilidad grave del kernel de Linux (CVE-2026-98432, CVSS 9.8) en la pila TCP IPv4 permite un use-after-free durante el handshake de TCP, que Anthropic demostró que puede convertirse en un exploit remoto con privilegios de root, especialmente en sistemas con listeners de multipath TCP (MPTCP). Los comentaristas se centran en el impacto práctico y las mitigaciones: muchas distribuciones y OpenWrt siguen desplegando kernels corregidos, MPTCP a menudo puede deshabilitarse, y se sugiere descartar paquetes IPv4 con opciones IP en el firewall o mediante XDP como salvaguarda parcial, aunque no como solución completa. Hay una preocupación amplia por routers y dispositivos IoT sin parchear, debate sobre la rapidez con la que proveedores como Ubuntu y RHEL deberían responder, y reflexión sobre cómo el descubrimiento de vulnerabilidades impulsado por IA y el C inseguro en subsistemas críticos están reconfigurando el panorama de seguridad.

Alcance y naturaleza de la vulnerabilidad

  • Use-after-free en el manejo de TCP IPv4 de Linux durante el handshake, en código que se ejecuta antes de que el tráfico llegue a las aplicaciones.
  • Un exploit exitoso puede lograr ejecución remota de código como root en los kernels afectados.
  • Se informa que la ruta IPv6 no se ve afectada; el problema está vinculado al manejo de opciones de IPv4.
  • El exploit es más fácil en sistemas multinúcleo; las configuraciones de un solo núcleo o una sola cola pueden ser, en la práctica, seguras.

Papel de Multipath TCP (MPTCP)

  • Desacuerdo en el hilo:
    • Una línea de discusión: exploitabilidad demostrada mediante listeners de MPTCP (por ejemplo, Go 1.24 habilitando MPTCP por defecto, algunos servidores como Caddy/Tailscale usándolo).
    • Otros enfatizan que el error está en el código genérico de TCP; MPTCP solo hizo más fácil la prueba de concepto, y también podría ser explotable una ruta que no use MPTCP.
  • Aclaración de que MPTCP usa opciones de TCP, mientras que el error está en opciones IP; se señala explícitamente cierta confusión aquí.

Quiénes se ven afectados

  • Se dice que todos los kernels de Linux desde 4.4 hasta ciertas versiones corregidas específicas (por ejemplo, 5.15.225, 6.1.190, etc.) están afectados.
  • Distribuciones principales:
    • Debian ya ha publicado correcciones; se critica a Ubuntu y RHEL por ir con retraso, aunque Ubuntu tiene kernels en “proposed” y RHEL se entrega con MPTCP deshabilitado por defecto.
    • Proxmox informa que ya había publicado kernels parcheados antes mediante su propia canalización.
  • OpenWrt y otras distribuciones para routers a menudo ejecutan kernels vulnerables, aunque los servicios expuestos a WAN pueden estar cerrados o filtrados por firewall de forma predeterminada.

Mitigaciones y explotabilidad práctica

  • Mitigaciones sugeridas comunes:
    • Deshabilitar MPTCP (net.mptcp.enabled = 0 en sysctl, banderas GODEBUG/go.mod de Go).
    • Filtrar paquetes IPv4 con opciones IP a nivel de firewall (iptables/nftables/ufw; XDP para mayor garantía).
  • Algunos señalan que muchos routers de ISP y de empresa ya descartan las opciones IP; otros argumentan que esto no es universal.
  • Exploit de laboratorio informado: ~48 minutos para filtrar una dirección de kernel, más ~5 minutos para obtener una shell.

Routers, IoT y equipos de consumo

  • Preocupación de que muchos dispositivos embebidos (routers, gadgets “smart”) ejecuten versiones vulnerables de Linux pero nunca reciban actualizaciones.
  • Consolación parcial: algunas cajas IoT baratas pueden ser de un solo núcleo o usar kernels antiguos; otros señalan que ahora son comunes los routers de consumo multinúcleo.

Ecosistema y debate operativo

  • Fuerte crítica a la respuesta lenta de las distribuciones “empresariales” frente al elogio a proyectos de movimiento más rápido.
  • Algunos administradores apagaron o bloquearon agresivamente servidores hasta que lleguen los parches.
  • Se discute que las CVE críticas constantes + el descubrimiento de exploits asistido por LLM pueden obligar a ciclos de parcheo más cortos y a un mejor aislamiento (VMs, bastiones, VLANs).

Lenguajes, arquitectura e IA

  • Renovados llamados a más Rust y a pilas de red seguras frente a fallos de memoria; contraargumentos de que las reescrituras introducen nuevos errores (no de memoria) y a menudo siguen dependiendo de unsafe.
  • Se menciona que partes del kernel de Linux ya se están trasladando a Rust (por ejemplo, controladores específicos).
  • Opiniones divididas sobre los LLM:
    • Se ven como herramientas poderosas para encontrar y convertir en arma bugs.
    • Preocupa que la IA impulse una “inundación de CVE”, pero también hay optimismo de que sacar a la luz errores antiguos podría volver los sistemas más seguros a largo plazo.

Actitudes e incertidumbre

  • Algunos lo tratan como una cuasi emergencia para servidores Linux expuestos públicamente; otros lo minimizan como difícil de explotar a través de Internet en general y un “nothingburger” una vez consideradas las mitigaciones y los balanceadores de carga.
  • Varias preguntas siguen sin estar claras en el hilo, incluida la explotabilidad exacta detrás de varios middleboxes y si todas las reglas de firewall sugeridas mitigan completamente las rutas que no usan MPTCP.