# Use-after-free en la capa TLS del kernel Linux: el cierre de socket que pisa memoria - **Publicado el:** 2026-06-02 - **Categoría:** Seguridad - **Página original:** https://linuxgratis.com/articulos/tls-ulp-use-after-free-tls-sk-proto-close-kernel-linux Una condición de carrera en tls_sk_proto_close() del kernel Linux permite un use-after-free al cerrar un socket TLS mientras otro hilo cambia opciones. Divulgada en oss-security el 2 de junio de 2026. --- 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](/linux-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():