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 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(): https://www.openwall.com/lists/oss-security/2026/06/02/12