Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAJv4Csu5=C04SfEWEWe7QuUTTYbwRieTxCXQ4chO3tPXDvGxHw@mail.gmail.com>
Date: Tue, 2 Jun 2026 22:59:22 +0300
From: Oleg Sevostyanov <savant05@...il.com>
To: oss-security@...ts.openwall.com
Subject: Linux kernel TLS ULP use-after-free in tls_sk_proto_close()

Hello oss-security,

I am disclosing a Linux kernel vulnerability in the TLS ULP subsystem.

Affected component:
  Linux kernel TLS ULP
  File: net/tls/tls_main.c
  Function: tls_sk_proto_close()

Vulnerability type:
  Use-after-free / race condition

Summary:
  There is a race between close() and setsockopt(SOL_TLS, TLS_TX) in the
  Linux kernel TLS ULP subsystem. Under certain interleavings, one thread
can
  close a TLS socket while another thread is still operating on TLS-related
  socket state through setsockopt(). This can lead to a use-after-free in
the
  TLS socket teardown path.

Impact:
  A local unprivileged user may be able to trigger kernel heap memory
  corruption. Based on my analysis, this may potentially be exploitable for
  local privilege escalation, although I do not have a confirmed full
privilege
  escalation exploit.

Affected versions:
  The affected version range is still being confirmed.

Kernel configuration:
  The issue affects systems with CONFIG_TLS enabled. On many distributions
this
  is built as a module.

Status:
  This issue was reported to linux-distros on 2026-05-16. I incorrectly
  contacted linux-distros before first getting a fix accepted by the Linux
  kernel maintainers. The latest proposed public disclosure date was
  2026-05-30, and this oss-security posting is being made late.

  As of this posting, I do not have an accepted upstream fix commit to cite.
  I am available to work with the kernel TLS/networking maintainers to
validate
  the issue and test a fix.

Reproducer:
  I have a reproducer for the race. I am not including it in this initial
public
  posting to avoid unnecessarily increasing harm before a fix is available,
but
  I can share it with kernel maintainers on request.

CVE:
  No CVE has been assigned as far as I know. I understand that the Linux
kernel
  CNA generally assigns CVEs after a fix commit is available.

AI disclosure:
  AI assistance was used during analysis and report preparation.
Specifically,
  OpenAI Codex was used to help inspect the relevant code path, reason about
  the race condition, and draft portions of the vulnerability report. I
reviewed
  and take responsibility for the report contents.

References:
  Linux kernel security bug process:
  https://docs.kernel.org/process/security-bugs.html

  Related but different public KTLS issue:
  https://www.openwall.com/lists/oss-security/2026/05/07/1

Timeline:
  2026-05-16: Reported to linux-distros
  2026-05-30: Latest agreed public disclosure date
  2026-06-02: Public disclosure to oss-security

Regards,
Oleg Sevostyanov

Content of type "text/html" skipped

View attachment "report-tls-uaf-en.md" of type "text/markdown" (14812 bytes)

Download attachment "poc-tls-uaf-race.c" of type "application/octet-stream" (14134 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.