[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJv4CssaPRCG40QqABsMj89riidUxAO35LVns_X=Df-+qfThpQ@mail.gmail.com>
Date: Wed, 3 Jun 2026 12:16:51 +0300
From: Oleg Sevostyanov <savant05@...il.com>
To: jcb62281@...il.com
Cc: oss-security@...ts.openwall.com
Subject: Re: Linux kernel TLS ULP use-after-free in tls_sk_proto_close()
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@...il.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
>
>
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.
