Re: [PATCH AUTOSEL 6.18-6.1] tls: reject the combination of TLS and sockmap
From: Sabrina Dubroca
Date: Tue Sep 01 2026 - 07:07:52 EST
2026-08-31, 09:30:24 -0400, Sasha Levin wrote:
> From: Jakub Kicinski <kuba@xxxxxxxxxx>
>
> [ Upstream commit 460e6486617c17dd19abe8f3fc67d9a6fa25f8ca ]
>
> 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).
>
> This patch is a minimal rejection of the feature. Subsequent patch
> in the series will do a light dead code removal. Full cleanup would
> require a major rewrite of the Tx path, we don't need skmsg any more.
>
> Reviewed-by: Jakub Sitnicki <jakub@xxxxxxxxxxxxxx>
> Reviewed-by: Sabrina Dubroca <sd@xxxxxxxxxxxxxxx>
> Link: https://patch.msgid.link/20260614014102.461064-2-kuba@xxxxxxxxxx
> Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> ---
>
> LLM Generated explanations, may be completely bogus:
330L... wow.
> ## Phase 1: Commit Message Forensics
>
> ### Step 1.1: Subject line
> **Record:** `[tls]` / `reject` — reject the unsupported TLS + sockmap
> (BPF psock) configuration.
>
> ### Step 1.2: Tags
> **Record:**
> - **Reviewed-by:** Jakub Sitnicki `<jakub@xxxxxxxxxxxxxx>`
> - **Reviewed-by:** Sabrina Dubroca `<sd@xxxxxxxxxxxxxxx>`
> - **Link:**
> https://patch.msgid.link/20260614014102.461064-2-kuba@xxxxxxxxxx
> - **Signed-off-by:** Jakub Kicinski `<kuba@xxxxxxxxxx>`
> - No Fixes:, Reported-by:, Cc: stable@xxxxxxxxxxxxxxx, or syzbot tags
Yes, this was intentionally sent to net-next without a Fixes tag,
because it's a "feature-level" change, so it kind of feels wrong to
send that to stable (even if it's removing a feature that nobody seems
to be using). OTOH the code is broken and not really fixable...
--
Sabrina