[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fb77a57b-82e7-4e72-8ec5-a30fe9c1b3db@gmail.com>
Date: Wed, 3 Jun 2026 22:40:22 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: Oleg Sevostyanov <savant05@...il.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Linux kernel TLS ULP use-after-free in
tls_sk_proto_close()
On 6/3/26 04:16, Oleg Sevostyanov wrote:
> 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.
The pattern of deferring a lock that will be unconditionally acquired
would be a good target for a broader locking audit.
Having the lock functions return a dummy value so that acquiring a lock
can be the first executable step, as part of local variable
initialization, is a more radical solution to this category of problem.
The "unused variable" problem could be resolved by making that return
value a "lock cookie" that will be later passed to the corresponding
unlock function.
-- 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.
