El 2 de junio de 2026 Oleg Sevostyanov publicó en la lista oss-security de Openwall un fallo en el subsistema TLS del kernel Linux. El problema está en tls_sk_proto_close(), dentro de net/tls/tls_main.c, y es una condición de carrera que termina en un use-after-free.
Qué falla exactamente
El kernel implementa parte de TLS dentro del propio núcleo mediante la ULP (Upper Layer Protocol) tls. Cuando una aplicación añade esa capa a un socket, el kernel reserva estado asociado a la conexión. Ese estado se libera al cerrar el socket.
La carrera ocurre entre dos hilos que tocan el mismo socket a la vez. Uno cierra la conexión y pasa por tls_sk_proto_close(), que desmonta y libera el estado TLS. El otro sigue operando sobre ese mismo socket mediante setsockopt(), todavía apoyándose en la configuración TLS. Si el orden se cruza, el segundo hilo trabaja sobre memoria que el primero ya liberó. De ahí el use-after-free.
A quién afecta
Afecta a kernels con CONFIG_TLS activado. En muchas distribuciones esa opción se compila como módulo y se carga bajo demanda, así que basta con que el módulo tls esté disponible y una aplicación use kTLS. El disparo no requiere privilegios especiales: un usuario local sin permisos puede provocar la carrera con dos hilos sobre un mismo descriptor.
Si en tu sistema nada usa kTLS y el módulo no está cargado, la superficie real es menor, pero conviene no confiarse: cualquier proceso local puede cargar y ejercitar el camino vulnerable.
Gravedad
El informe la clasifica como severidad alta. Un use-after-free en memoria de kernel puede degenerar en corrupción del heap y, en el peor caso, abrir la puerta a una escalada de privilegios local. Sevostyanov no publicó un exploit funcional ni demostró ejecución de código; describió el patrón y retuvo el reproductor para no facilitar ataques antes del parche. Aun así, el historial de fallos similares en el kernel aconseja tratarlo en serio.
Conviene anotar el contexto: el reporte se envió a la lista privada linux-distros el 16 de mayo de 2026 y se hizo público el 2 de junio. En el momento de la divulgación no había todavía CVE asignado (el CNA del kernel suele asignarlo cuando hay corrección disponible) ni commit upstream publicado. El propio autor menciona que usó asistencia de IA para el análisis.
Mitigación
La vía correcta es actualizar el kernel en cuanto tu distribución publique el paquete con la corrección de tls_sk_proto_close(). Revisa los avisos de seguridad de tu proveedor (Debian, Ubuntu, Red Hat, SUSE y demás) y aplica el kernel parcheado en cuanto esté disponible.
Mientras tanto, si una máquina no necesita kTLS, puedes reducir la exposición evitando cargar el módulo. Una opción es ponerlo en la lista de bloqueo de módulos con blacklist tls en /etc/modprobe.d/, siempre que ninguna aplicación dependa de TLS en kernel. No es una solución, solo recorta la superficie hasta que llegue el parche.
Si gestionas servidores Linux, vigila el seguimiento del kernel y prioriza el reinicio tras actualizar, ya que un kernel nuevo no entra en uso hasta que la máquina arranca con él (salvo que uses live patching).
Fuente
- oss-security (Openwall), Linux kernel TLS ULP use-after-free in tls_sk_proto_close(): https://www.openwall.com/lists/oss-security/2026/06/02/12