# Use-after-free a la capa TLS del kernel Linux: el tancament de socket que trepitja memòria - **Publicat el:** 2026-06-02 - **Categoria:** Seguretat - **Pàgina original:** https://linuxgratis.com/ca/articles/tls-ulp-use-after-free-tls-sk-proto-close-kernel-linux Una condició de cursa a tls_sk_proto_close() del kernel Linux permet un use-after-free en tancar un socket TLS mentre un altre fil canvia opcions. Divulgada a oss-security el 2 de juny de 2026. --- El 2 de juny de 2026 l'Oleg Sevostyanov va publicar a la llista oss-security d'Openwall un error al subsistema TLS del kernel Linux. El problema és a `tls_sk_proto_close()`, dins de `net/tls/tls_main.c`, i és una condició de cursa que acaba en un use-after-free. ## Què falla exactament El kernel implementa part de TLS dins del nucli mateix mitjançant la ULP (Upper Layer Protocol) `tls`. Quan una aplicació afegeix aquesta capa a un socket, el kernel reserva estat associat a la connexió. Aquest estat s'allibera en tancar el socket. La cursa passa entre dos fils que toquen el mateix socket alhora. Un tanca la connexió i passa per `tls_sk_proto_close()`, que desmunta i allibera l'estat TLS. L'altre continua operant sobre aquest mateix socket mitjançant `setsockopt()`, encara recolzant-se en la configuració TLS. Si l'ordre es creua de la manera dolenta, el segon fil treballa sobre memòria que el primer ja ha alliberat. D'aquí ve el use-after-free. ## A qui afecta Afecta kernels amb `CONFIG_TLS` activat. En moltes distribucions aquesta opció es compila com a mòdul i es carrega sota demanda, així que n'hi ha prou que el mòdul `tls` estigui disponible i que alguna aplicació faci servir kTLS. El dispar no demana privilegis especials: un usuari local sense permisos pot provocar la cursa amb dos fils sobre un mateix descriptor. Si al teu sistema res no fa servir kTLS i el mòdul no es carrega mai, la superfície real és menor. Tot i això, no et confiïs: qualsevol procés local pot carregar i exercir el camí vulnerable. ## Gravetat L'informe la classifica com a severitat alta. Un use-after-free a la memòria del kernel pot degenerar en corrupció del heap i, en el pitjor cas, obrir la porta a una escalada de privilegis local. Sevostyanov no va publicar cap exploit funcional ni va demostrar execució de codi; va descriure el patró i va retenir el reproductor per no facilitar atacs abans del pedaç. Tot i així, l'historial d'errors semblants al kernel aconsella prendre-s'ho seriosament. Val la pena anotar el context: el report es va enviar a la llista privada linux-distros el 16 de maig de 2026 i es va fer públic el 2 de juny. En el moment de la divulgació encara no hi havia cap CVE assignat (el CNA del kernel sol assignar-lo quan hi ha correcció disponible) ni cap commit upstream publicat. El mateix autor esmenta que va fer servir assistència d'IA durant l'anàlisi. ## Mitigació La via correcta és actualitzar el kernel tan bon punt la teva distribució publiqui el paquet amb la correcció de `tls_sk_proto_close()`. Revisa els avisos de seguretat del teu proveïdor (Debian, Ubuntu, Red Hat, SUSE i altres) i aplica el kernel pedaçat quan estigui disponible. Mentrestant, en una màquina que no necessita kTLS, pots reduir l'exposició evitant que el mòdul es carregui. Una opció és posar-lo a la llista de bloqueig amb `blacklist tls` a `/etc/modprobe.d/`, sempre que cap aplicació depengui de TLS al kernel. No és una solució, només retalla la superfície fins que arribi el pedaç. Si gestiones servidors Linux, vigila el [seguiment del kernel](/ca/linux-kernel) i planifica el reinici després d'actualitzar, ja que un kernel nou no entra en ús fins que la màquina arrenca amb ell (tret que facis servir live patching). ## Font - oss-security (Openwall), Linux kernel TLS ULP use-after-free in tls_sk_proto_close():