Re: Linux kernel TLS ULP use-after-free in tls_sk_proto_close()

[Jacob Bachmeyer <jcb62281 () gmail com>]

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