UAF en TCP del kernel de Linux: parchear o mitigar

Tu kernel tiene un use-after-free accesible remotamente en la ruta del handshake TCP, tu distribución todavía no ha publicado un arreglo y alguien ya ha demostrado un exploit funcional para obtener root. Entonces, ¿cuál es el plan: esperar sentado o empezar a descartar paquetes en el firewall? El use-after-free en TCP de Linux revelado como CVE-2026-98432 es un caso de estudio limpio de la decisión más antigua de las operaciones de seguridad: parchear frente a mitigar. Y la respuesta honesta es que las dos opciones no son simétricas. Una de ellas soluciona de verdad el problema.

He estado en los dos lados de esta decisión. He retrasado un despliegue urgente del kernel porque la mitigación parecía suficiente sobre el papel, y también he visto cómo una regla temporal del firewall se pudría en producción durante ocho meses mientras todos se olvidaban del CVE que tapaba. Este fallo es un buen detonante para hablar de cuándo gana cada enfoque, porque aquí los compromisos son inusualmente claros.

Qué es realmente el use-after-free en TCP

La mecánica importa porque determina lo que una mitigación puede y no puede hacer. Cuando tu servidor acepta una conexión TCP sobre IPv4, el kernel rastrea el handshake a medio abrir en un request socket ligero y luego lo promociona a socket completo cuando el handshake termina. Si la cabecera IPv4 del peer traía opciones, el kernel las guarda para incluirlas en sus respuestas. El fallo: el kernel pasaba esas opciones guardadas a la nueva conexión sin copiarlas y luego las liberaba de inmediato, mientras otra CPU todavía podía estar leyéndolas para construir la respuesta del handshake. Es un use-after-free alcanzable por un peer remoto y no autenticado, antes de que se ejecute una sola línea de tu aplicación.

El arreglo upstream, de Eric Dumazet, son cuatro líneas: dos llamadas a kfree() simples pasan a ser kfree_rcu(), que aplaza la liberación hasta que todos los lectores han terminado con la memoria. Es el arreglo canónico del kernel para esta clase de error: los lectores bajo RCU mantienen referencias que no ves, así que dejas que expire el periodo de gracia antes de reclamar la memoria. El CNA del propio kernel le asignó un CVSS 9.8. Red Hat lo puntuó inicialmente con 8.1, pero lo subió a 9.8 (Critical) el 30 de octubre, alegando la ausencia de requisitos previos de red.

Dos detalles cambian las cuentas de exposición. Primero, la carrera falla sin dramas: un intento fallido simplemente aborta el handshake sin provocar un pánico en la máquina, así que un atacante puede reintentarlo indefinidamente. Segundo, la ruta de explotación que demostró Anthropic apunta a hosts con un listener de TCP multipath, y según el equipo de seguridad de Go, los programas en Go abren listeners MPTCP por defecto en Linux desde Go 1.24, siempre que el kernel lo permita. Revisa tu flota:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Una salida vacía de ss -M significa que no hay ningún listener MPTCP. Pero no te relajes: el equipo de Go es explícito en que el error de fondo no es específico de MPTCP. Es un UAF genérico en el procesamiento del handshake; MPTCP es simplemente la ruta que alguien ha probado de extremo a extremo.

La vía de parcheo: kernel corregido, reinicio, listo

Parchear es aburrido de describir porque es la única opción que elimina la vulnerabilidad en lugar de reconfigurarla. Los kernels corregidos se publicaron upstream los días 11 y 15 de octubre en todas las ramas estables mantenidas, y el bug se remonta a Linux 4.4, lo que significa que muchos sistemas de cola larga están afectados, incluidos kernels tan antiguos que upstream ya no toca.

El problema es el reinicio. Una actualización del kernel no hace nada hasta que la máquina arranca con ella, y ahí es donde está el coste operativo real: nodos de Kubernetes drenados, ensayos de failover, la primaria de la base de datos que nadie quiere tumbar en horario laboral. Por eso «solo parchea» siempre es correcto y nunca suficiente como consejo. Necesitas un plan de despliegue: primero hosts canary, después los tiers sin estado y por último los que tienen estado, con ventanas de mantenimiento. Si has pasado antes por una rotación de emergencia del kernel en toda la flota, ya conoces el procedimiento. Los equipos que lo gestionan bien son los que ensayaron el drenado de nodos cuando nada estaba ardiendo; los hábitos de ingeniería defensiva que construyes en martes tranquilos son los que rinden durante un 9.8.

Una trampa que conviene nombrar: que dpkg -l o rpm -q kernel muestren un paquete corregido no significa nada si el kernel en ejecución es anterior. uname -r te dice qué está realmente ejecutándose. En las distribuciones tipo RHEL, needs-restarting -r te indicará claramente si hay un reinicio pendiente. He revisado informes posteriores a incidentes en los que la flota «parcheada» era una flota de kernels instalados pero no en ejecución. Verifica la versión en ejecución contra el tracker de tu distribución, no contra el número upstream, porque los kernels de las distros llevan backports bajo su propio versionado.

La vía de mitigación: descartar opciones IPv4, desactivar MPTCP

La mitigación provisional publicada es una regla de nftables que descarta los paquetes TCP IPv4 entrantes que llevan opciones IP, la condición desencadenante de la ruta vulnerable. Puedes complementarla desactivando MPTCP (sysctl -w net.mptcp.enabled=0) si no lo usas. Ambas medidas son rápidas, no requieren reinicio y se pueden desplegar con tu herramienta de gestión de configuración en una tarde. Ese es su atractivo.

Ahora la parte que debería templar tu entusiasmo: el boletín del propio Red Hat dice que su regla «reduce la exposición a esta vulnerabilidad, pero no puede prevenirla por completo». Léelo dos veces. La mitigación reduce la superficie de ataque; no la cierra. Los paquetes con opciones IP son raros en el tráfico normal, y la mayoría de los middleboxes los descartan de todos modos, que es una de las razones por las que se considera improbable la explotación desde internet abierta. Pero «raro» e «imposible» son palabras distintas, y el fallo está en código genérico del handshake, no solo en la ruta de opciones que alguien casualmente probó.

Hay además un coste más sutil: las mitigaciones crean una falsa sensación de cierre. El ticket pasa a «casi hecho», la urgencia se diluye en el esfuerzo de parcheo y seis semanas después sigues ejecutando un kernel vulnerable detrás de un filtro de paquetes, con una memoria institucional de por qué lo pusiste que se desvanece rápido. He escrito sobre este patrón antes en el contexto de la ventana de CVEs críticos de PHP, donde los equipos que simplemente retiraron lo vulnerable de producción salieron mejor parados que los que apilaron filtros ingeniosos. Misma lección, otra pila.

Parchear o mitigar: cuándo gana cada una

Aquí va mi tabla de decisiones honesta, tras años tomando esta decisión bajo presión.

• Hay kernel corregido para tu distribución. Gana parchear, sin discusión. Debian, SUSE Enterprise, Oracle UEK y Amazon Linux han publicado arreglos. No existe una mitigación más ingeniosa que un arreglo upstream de cuatro líneas. Programa los reinicios, despliega por anillos y sigue adelante.
• Aún no hay kernel corregido y la exposición es real. Mitiga de inmediato: para eso existen las mitigaciones. Ubuntu y RHEL seguían «Vulnerable»/«afectados» a finales de octubre. Si estás expuesto a internet con un listener MPTCP, descarta los paquetes con opciones IP y desactiva MPTCP hoy, mientras sigues el kernel corregido como una release que estás bloqueando.
• Expuesto a internet pero detrás de una entrada gestionada. Tu urgencia baja. La guía de AWS, según la cual el tráfico que pasa por sus load balancers, CloudFront o API Gateway no llega a tus instancias como TCP crudo y no confiable, es sólida. Mitiga igualmente (es barato) y parchea dentro de un ciclo normal en lugar de uno de emergencia.
• Sistemas de un solo núcleo o una sola cola. Prioridad más baja. La carrera necesita procesamiento concurrente de paquetes en varias CPU. Los sistemas embebidos y las VMs pequeñas ganan algo de margen, pero también suelen ser las máquinas que nadie reinicia nunca, así que no dejes que «baja prioridad» se convierta en «nunca».
• Kernels al final de su vida (upstream anteriores a 5.10). La mitigación es tu única opción independiente de upstream. Este es el escenario en el que las mitigaciones ganan de verdad, porque la alternativa es un backport del proveedor que quizá nunca llegue. Además, es una señal clara de que la propia máquina es la vulnerabilidad, y el arreglo real es reemplazarla.

El problema de las distribuciones es la verdadera historia

El detalle que debería preocuparte no es el fallo: las correcciones de use-after-free de cuatro líneas llegan a los kernels estables todos los meses. Lo preocupante es que dos de las mayores distribuciones de servidores del planeta, Ubuntu y RHEL, seguían sin arreglos publicados más de dos semanas después de upstream, mientras que Amazon Linux había parcheado todos sus kernels y AlmaLinux, una reconstrucción comunitaria, tenía kernels corregidos en pruebas antes que su upstream. La comunidad de HN lo notó y tiene razón en estar molesta: son las distribuciones que más se promocionan por su madurez para servidores.

Para quien trabaja en operaciones, la conclusión es poco vistosa: tu ventana de exposición la define el pipeline de backports de tu proveedor, no upstream. Eso exige dos cosas. Primero, conoce las URLs de los trackers de tu distribución y revísalas de verdad: este CVE estuvo en «Received» en NVD sin análisis mientras el CNA del kernel, Red Hat y las distribuciones ya tenían páginas detalladas. Segundo, trata la capacidad de respuesta de la distribución como criterio de selección. Amazon Linux acaba de demostrar un pipeline de arreglos del kernel bastante más rápido que los dos grandes. Eso no importará en una presentación comercial, pero sí importa el fin de semana de Halloween cuando cae un 9.8.

El exploit escrito con IA cambia el reloj

La frase más importante del aviso es fácil de pasar por alto: Anthropic informa de que su modelo Claude produjo un exploit funcional de root remoto, tras un prompt inicial y menos de una hora de tiempo de máquina para ir desde una fuga de punteros del kernel hasta una shell de root. No lo han publicado, y los escépticos en HN se rieron del tono de «confía en nosotros». Justo. Pero incluso descontando el marketing, la dirección es inequívoca: el tiempo entre «el diff llega al árbol estable» y «existe un exploit funcional» se está desplomando, porque el cuello de botella nunca fue el fallo, sino la persona capaz de leer el diff y hacer el heap grooming.

Esto acorta la ventana de decisión entre parchear y mitigar. Cuando desarrollar un exploit tardaba semanas, «mitiga ahora, parchea en la próxima ventana de mantenimiento» era defendible. Cuando un modelo puede sacar un PoC de la noche a la mañana a partir de un commit público, tu fase de mitigación debe medirse en horas y la de parcheo en días. El arreglo de cuatro líneas es público. Cualquiera puede estudiarlo. Asume que el exploit también lo es.

Mi recomendación

Parchea. Mitiga solo como puente, y ponle fecha de caducidad a ese puente. En concreto: si tu distribución tiene un kernel corregido, empieza a desplegarlo ya y verifica uname -r tras cada reinicio. Si usas Ubuntu o RHEL, despliega hoy el descarte de opciones IP y desactiva MPTCP, y trata el arreglo del kernel que falta como una dependencia bloqueante: revisa el tracker a diario, no semanalmente. Prioriza lo que esté expuesto a internet con un listener MPTCP y, después, todo lo demás que acepte TCP entrante, que es casi todo. Los contenedores no te salvan: comparten el kernel del host, así que parchea los nodos.

La lección de fondo es la que este fallo enseña cada pocos años con un número CVE nuevo: las mitigaciones compran tiempo, pero solo los parches cierran agujeros, y el tiempo que compran las mitigaciones es cada vez menor. Entrena la capacidad de desplegar kernels de forma rápida y segura antes de necesitarla, porque el próximo arreglo de cuatro líneas ya está esperando en la cola de alguien.