On 2 June 2026 Oleg Sevostyanov posted a flaw in the Linux kernel’s TLS subsystem to Openwall’s oss-security list. The bug sits in tls_sk_proto_close(), inside net/tls/tls_main.c, and it’s a race condition that ends in a use-after-free.
What goes wrong
The kernel runs part of TLS in the core itself through the tls ULP (Upper Layer Protocol). When an application attaches that layer to a socket, the kernel allocates connection state. That state gets freed when the socket closes.
The race happens between two threads touching the same socket at once. One closes the connection and runs through tls_sk_proto_close(), which tears down and frees the TLS state. The other keeps operating on that same socket through setsockopt(), still leaning on the TLS configuration. If the ordering interleaves the wrong way, the second thread works on memory the first one already freed. That’s the use-after-free.
Who it affects
This hits kernels built with CONFIG_TLS enabled. On many distributions that option ships as a module loaded on demand, so it’s enough for the tls module to be available and for some application to use kTLS. Triggering it needs no special privileges: a local unprivileged user can drive the race with two threads on the same descriptor.
If nothing on your system uses kTLS and the module is never loaded, the practical attack surface is smaller. Don’t read too much into that, though: any local process can load and exercise the vulnerable path.
Severity
The report rates it high severity. A use-after-free in kernel memory can decay into heap corruption and, in the worst case, open the door to local privilege escalation. Sevostyanov did not publish a working exploit or demonstrate code execution; he described the pattern and held back the reproducer to avoid handing attackers a head start before a patch landed. Given the kernel’s track record with bugs of this shape, it deserves to be taken seriously.
Worth noting on the timeline: the report went to the private linux-distros list on 16 May 2026 and became public on 2 June. At disclosure there was no CVE assigned yet (the kernel CNA usually assigns one once a fix exists) and no upstream commit published. The author also mentions he used AI assistance during the analysis.
Mitigation
The right move is to update the kernel as soon as your distribution ships the package carrying the tls_sk_proto_close() fix. Watch your vendor’s security advisories (Debian, Ubuntu, Red Hat, SUSE and others) and roll out the patched kernel once it’s available.
In the meantime, on a machine that has no need for kTLS, you can cut exposure by keeping the module from loading. One option is to blacklist it with blacklist tls in /etc/modprobe.d/, as long as no application depends on in-kernel TLS. This isn’t a fix, only a way to shrink the surface until the patch arrives.
If you run Linux servers, keep an eye on the kernel tracker and plan the reboot after updating, since a new kernel doesn’t take over until the machine boots into it (unless you use live patching).
Source
- 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