Linux Kernel TLS Race Exposes Unpatched LPE Risk
Key insights
- Researcher Oleg Sevostyanov disclosed a use-after-free in Linux kernel's tls_sk_proto_close() on June 2 with no CVE and no upstream patch committed.
- The race between close() and setsockopt(SOL_TLS, TLS_TX) can trigger kernel heap memory corruption on any system with CONFIG_TLS compiled in.
- A working reproducer exists and was shared with kernel maintainers on request, but was withheld from public disclosure at posting time.
Why this matters
CONFIG_TLS is commonly compiled as a module across many Linux distributions, meaning the attack surface for this kernel heap corruption candidate is broad and largely unpatched as of disclosure. The post arrived on oss-security with no upstream fix commit and no CVE, leaving defenders without a patch-tracking anchor while the vulnerability is already public knowledge. The reporter's disclosed use of OpenAI Codex for code analysis and report preparation marks a concrete, named instance of AI tooling accelerating kernel-class vulnerability discovery and disclosure.
Summary
A use-after-free race in the Linux kernel's TLS subsystem was publicly disclosed June 2 by Oleg Sevostyanov, with no patch and no CVE assigned at disclosure time.
The bug lives in tls_sk_proto_close() in net/tls/tls_main.c. When close() and setsockopt(SOL_TLS, TLS_TX) run concurrently, the kernel can reach freed memory during socket teardown, potentially triggering kernel heap memory corruption. A reproducer exists and was shared with kernel maintainers on request, but withheld from public disclosure.
Essentially: Oleg Sevostyanov, linux-distros, oss-security.
- Private report to linux-distros May 16; agreed May 30 deadline slipped to June 2.
- Affects any system with CONFIG_TLS compiled in, commonly built as a module on many distributions.
- Reporter used OpenAI Codex for code analysis and report preparation, while maintaining responsibility for the contents.
The disclosure arrived without an upstream fix or CVE, placing distribution teams in reactive mode against a now-public bug with an existing reproducer.
Potential risks and opportunities
Risks
- Linux distribution maintainers face an open exposure window with no upstream patch to backport while the vulnerability and its mechanism are now public on oss-security.
- Threat actors who obtained the privately shared reproducer between May 16 and June 2 could be ahead of defenders on exploitation capability before a patch lands.
- Systems running shared multi-tenant Linux environments with CONFIG_TLS enabled face elevated lateral-movement risk if the local privilege escalation potential moves from 'possible' to confirmed.
Opportunities
- Kernel security monitoring vendors can differentiate on behavioral detection coverage for exploit attempts targeting tls_sk_proto_close() during the window before an upstream patch lands.
- Organizations with CONFIG_TLS-enabled kernels have immediate justification to audit kernel module configurations and restrict concurrent TLS socket operations as a mitigating control.
- AI-assisted security research platforms can cite OpenAI Codex's named role in this disclosure as concrete evidence that AI tooling now surfaces kernel-class vulnerabilities, strengthening product positioning for both offensive research and defensive tooling.
What we don't know yet
- Whether a CVE has been assigned or an upstream fix committed since the June 2 oss-security post, given neither existed at disclosure time.
- Whether the reproducer shared privately with kernel maintainers has circulated beyond that group between the May 16 report and the June 2 public disclosure.
- Which Linux distribution security teams have begun backporting a fix independently, given no upstream commit existed at the time of public disclosure.
Originally reported by seclists.org
Read the original article →Original headline: Linux Kernel TLS ULP Use-After-Free Disclosed — Local Privilege Escalation Potential, No CVE Assigned, No Patch Available