Problema

En entornos donde se delega la terminación TLS al kernel (kTLS), el flujo de recepción de datos depende de una ruta de código que asume la existencia de un socket buffer (skb) para cada registro TLS. Cuando un registro TLS 1.3 de longitud cero llega desde la lista de recepción (rx_list), el kernel escribe directamente en el buffer de usuario sin crear un skb. La lógica posterior del bucle de recepción, sin embargo, sigue esperando un skb y termina accediendo a memoria no inicializada. El resultado es una condición de desreferencia que permite la ejecución arbitraria de código en el contexto del proceso que consume la conexión.

Este patrón no es exclusivo de la CVE‑2025‑39682; cualquier implementación que combine:

  1. kTLS activado en modo de recepción,
  2. manejo de registros TLS 1.3 de longitud cero,
  3. asunción implícita de que siempre habrá un skb,

puede reproducir la vulnerabilidad. La exposición depende de que la aplicación habilite kTLS para la ruta de receive (por ejemplo, Nginx o HAProxy con offload TLS) y de que el atacante pueda inyectar un registro TLS 1.3 vacío, algo factible en configuraciones que aceptan conexiones sin autenticación mutua o que permiten renegociaciones.

Causa

1. Suposición implícita de skb

El código original del kernel trata los registros TLS como si siempre provinieran de una copia en memoria (skb). Cuando se introduce la optimización de zero‑copy para kTLS, esa suposición se rompe para los registros de longitud cero, que se entregan directamente al espacio de usuario.

2. Falta de validación del tipo de registro

El bucle de procesamiento verifica el tipo de registro (handshake, application data, etc.) pero no controla que el registro provenga de rx_list. En el caso de un registro vacío, el cambio de tipo desencadena la ruta que espera un skb, provocando la desreferencia.

3. Configuración opcional de kTLS

kTLS es una característica opt‑in. Cuando está habilitado solo en la transmisión, el problema no se manifiesta. La combinación de receive‑side kTLS y zero‑copy es la que genera la vulnerabilidad.

4. Falta de pruebas de casos límite

Los tests de regresión del kernel no cubrían la combinación “registro TLS 1.3 de longitud cero + receive‑side kTLS”. Por eso la condición quedó sin detectar hasta que CISA la incluyó en su lista KEV.

Solución

A. Actualizar el kernel

La forma más directa es aplicar el parche oficial que corrige el manejo de registros cero. Las versiones que incluyen la corrección son:

  • 6.1.149
  • 6.6.103
  • 6.12.44
  • 6.16.4
  • 6.17

En distribuciones que no ofrecen esas versiones, usar los backports o compilar el árbol de fuentes con el commit de corrección.

B. Desactivar kTLS en recepción (si no es crítico)

Si la carga de trabajo no depende de la aceleración de recepción, desactivar kTLS elimina la superficie de ataque sin necesidad de actualizar el kernel.

# Verificar si kTLS está habilitado para receive
sysctl -a | grep net.ipv4.tcp_ktls

# Desactivar receive‑side kTLS globalmente
sysctl -w net.ipv4.tcp_ktls_rx=0

# Persistir en /etc/sysctl.conf
echo "net.ipv4.tcp_ktls_rx = 0" >> /etc/sysctl.conf
sysctl -p

C. Revisar configuraciones de aplicaciones

Algunas aplicaciones habilitan kTLS mediante flags o módulos. Por ejemplo, Nginx con ssl_engine kTLS; o HAProxy con tune.ssl.ciphersuites. Revise los archivos de configuración y elimine la opción de receive si no es indispensable.

D. Implementar validaciones de registro en capas superiores

Aunque el kernel ya corrige el bug, añadir una capa de defensa en la aplicación (por ejemplo, rechazando registros TLS 1.3 de longitud cero) reduce la exposición a futuros errores similares.

# Ejemplo con OpenSSL en modo servidor (pseudo‑código)
if (tls_record.length == 0 && tls_record.type == APPLICATION_DATA) {
    abort_connection();
}

E. Monitoreo y alertas

Configure alertas que detecten patrones inusuales en los logs de TLS, como intentos de envío de registros vacíos o errores de desreferencia en dmesg. Herramientas como auditd o journald pueden filtrar los mensajes del kernel relacionados con ktls.

Cuándo aplicar esta solución

  • Entorno de producción con kTLS habilitado en recepción: Priorice la actualización del kernel o la desactivación de tcp_ktls_rx.
  • Sistemas legacy sin soporte de kernel actualizado: Desactivar kTLS es la opción más segura.
  • Aplicaciones que usan offload TLS (Nginx, HAProxy, Envoy): Revise la configuración y desactive la recepción por kTLS si no se justifica la ganancia de rendimiento.
  • Entornos con bajo riesgo de explotación (red interna aislada): Puede postergar la actualización siempre que se mantenga la monitorización activa.

No aplique la solución si:

  • La carga de trabajo depende críticamente del rendimiento de recepción TLS y no hay alternativas de hardware que compensen la pérdida de kTLS.
  • La política de cumplimiento exige la versión exacta del kernel sin parches (casos muy raros).

Código

# 1. Comprobar versión del kernel
uname -r

# 2. Instalar kernel actualizado (Debian/Ubuntu ejemplo)
apt-get update
apt-get install -y linux-image-6.1.149-rt

# 3. Reiniciar en el nuevo kernel
reboot

# 4. Verificar que la corrección está presente
grep -i "zero-length" /usr/src/linux/Documentation/patches/ktls_fix.txt || echo "Patch not found"

Verificación

  1. Confirmar versión: uname -r debe mostrar una de las versiones con parche.
  2. Comprobar flag: sysctl net.ipv4.tcp_ktls_rx debe devolver 0 (si se desactivó) o 1 (si se mantiene y el kernel está parcheado).
  3. Reproducir caso de prueba: Use openssl s_client para abrir una conexión TLS 1.3 y envíe un registro vacío con una herramienta de fuzzing. El proceso no debe terminar con un kernel oops.
  4. Revisar logs: dmesg | grep -i ktls no debe contener mensajes de “NULL pointer dereference”.

Notas adicionales

  • En algunos entornos de contenedores, el kernel del host es el que controla kTLS; asegúrese de que la política de actualización se aplique a nivel de host, no solo dentro del contenedor.
  • La desactivación de tcp_ktls_rx no afecta la transmisión TLS mediante kTLS, por lo que la mayoría de los beneficios de rendimiento se conservan.
  • Mantenga un inventario de los servicios que usan kTLS; una auditoría trimestral ayuda a detectar configuraciones que se activaron por accidente tras actualizaciones de paquetes.
  • Si su organización usa herramientas de escaneo de vulnerabilidades, ajuste la puntuación CVSS a la realidad del entorno: un EPSS < 1 % indica baja probabilidad de explotación, pero la presencia de kTLS habilitado eleva el riesgo. Use ambos indicadores para priorizar parches.