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

[Jacob Bachmeyer <jcb62281 () gmail com>]

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