Re: [PATCH net-next 1/5] tls: reject the combination of TLS and sockmap

[Jakub Kicinski <kuba@kernel.org>]

On Sun, 14 Jun 2026 21:12:05 +0200 Jakub Sitnicki wrote:
> On Sun, Jun 14, 2026 at 10:09 AM +02, Paolo Abeni wrote:
> > On 6/14/26 3:40 AM, Jakub Kicinski wrote:  
> >> TLS and sockmap (BPF psock) integration hides a lot of latent bugs.
> >> Bugs which may be more or less relevant for real users but they
> >> are definitely exploitable.
> >> 
> >> We could not find anyone actively using this integration so let's
> >> reject this config. Adding a TLS socket to a sockmap was already
> >> rejected by sk_psock_init() through the inet_csk_has_ulp() check.
> >> We need to reject the attempts to configure the TLS keys (rather
> >> than adding the ULP itself) because checking prior to the ULP
> >> installation is tricky without risking a race with sockmap getting
> >> added in parallel (sockmap does not hold the socket lock).  
> >
> > Aren't both tls_ctx_create() and sk_psock_init() under (write) the
> > callback lock? Isn't that enough to avoid races?  
> 
> +1, but we would have to tweak inet_csk_has_ulp() to check for
> icsk_ulp_data in addition to icsk_ulp_ops. Only icsk_ulp_data is set
> under sk_callback_lock.
> 
> espintcp faces the same race...

Right, some deeper restructuring is needed for that. Also - I'm aware
of the race that Sashiko points out but we need to draw the line
somewhere if we want to hit the current merge window.

IOW I decided to keep it simple and focus on removing TLS+sockmap
integration, races in ULP vs sockmap init is a separate can of warms.