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 <[email protected]>: > 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 > >
