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
