[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dba33ac5-e1de-47d1-ac39-05fc42dfa3f4@gmail.com>
Date: Tue, 2 Jun 2026 22:02:28 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, Oleg Sevostyanov <savant05@...il.com>
Subject: Re: Linux kernel TLS ULP use-after-free in
tls_sk_proto_close()
On 6/2/26 14:59, Oleg Sevostyanov wrote:
> Hello oss-security,
>
> I am disclosing a Linux kernel vulnerability in the TLS ULP subsystem.
>
> [...]
>
> 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.
Looking at the kernel code in the report, I suspect that there is a
pattern here: a lock that will be unconditionally taken is deferred
until later instead of being taken at the first opportunity.
In this example, in tls_sk_proto_close, lock_sock(sk) is *always*
called, so there is no reason for it to not be the very first call after
the accessors that are used to initialize local variables.
In fact, maybe Linux should adopt a new pattern where lock_* functions
return a meaningless but non-void value, simply to allow moving them to
the very first step in a function, as the first local variable initializer.
>
> [...]
>
> 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.
At least you owned up to this; I believe this to be quite rare. (Not the
screw-up---admitting it---usually the list moderator ends up having to
make the public post as I recall.)
> [...]
>
> 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.
Oops; it was included in your message and is now in the public archives.
> [...]
>
> 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.
This is at least the proverbial breath of fresh air---the use of "AI"
openly admitted.
-- Jacob
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.
