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

[Oleg Sevostyanov <savant05 () gmail com>]

Thank you for the comments.

You are right about the reproducer. I mistakenly included it despite saying
that I was not including it. I apologize for the inconsistency.

I also agree that taking lock_sock(sk) earlier in tls_sk_proto_close() looks
like the natural mitigation direction, given that the function takes it
unconditionally anyway. I will bring this point to the kernel/networking
maintainers when discussing a fix.

Regards,
Oleg

ср, 3 июн. 2026 г. в 06:02, 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