[PATCH] tls: reject attaching TLS to sockets already in sockmap

[PATCH] tls: reject attaching TLS to sockets already in sockmap

[Xingwang Xiang]

When a socket is first inserted into a sockmap with a verdict program,
then TLS is enabled on that socket, the TLS strparser's saved_data_ready
callback becomes sk_psock_verdict_data_ready(). This function calls
tcp_read_skb() which drains ALL skbs from sk_receive_queue without
updating tp->copied_seq when the BPF verdict is SK_PASS. This leaves
tcp_inq() returning stale values, causing the TLS strparser to think
data exists in the receive queue when it doesn't.

The result is a WARN_ON_ONCE(!first) in tls_strp_load_anchor_with_queue()
when tcp_recv_skb() returns NULL, and Use-After-Free when
the strparser's frag_list points to skbs that have been unlinked and
are now owned by the sockmap subsystem.

While sk_psock_init() correctly checks inet_csk_has_ulp() to prevent
inserting TLS sockets into sockmaps (blocking "forward order"), tls_init()
does not check for an existing psock, allowing "reverse order" setup.

Fix this by adding a check in tls_init() to reject sockets that already
have a psock attached (i.e., are in a sockmap). This mirrors the
existing guard in sk_psock_init() and ensures mutual exclusion between
TLS and sockmap attachments regardless of the order of operations.

Signed-off-by: Xingwang Xiang <v3rdant.xiang@gmail.com>
---
 net/tls/tls_main.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index fd39acf41..d4ac91c50 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -1047,6 +1047,8 @@ static void build_protos(struct proto prot[TLS_NUM_CONFIG][TLS_NUM_CONFIG],
 static int tls_init(struct sock *sk)
 {
 	struct tls_context *ctx;
+	struct sk_psock *psock;
+
 	int rc = 0;
 
 	tls_build_proto(sk);
@@ -1056,6 +1058,20 @@ static int tls_init(struct sock *sk)
 		return 0;
 #endif
 
+	/* Reject sockets that are already attached to a sockmap.
+	 * The sockmap verdict path (sk_psock_verdict_data_ready) is
+	 * incompatible with TLS: it drains the receive queue via
+	 * tcp_read_skb() without updating copied_seq, causing the
+	 * TLS strparser to operate on stale queue state.
+	 * This mirrors the check in sk_psock_init() that rejects
+	 * sockets with ULP (TLS) from being inserted into sockmaps.
+	 */
+	rcu_read_lock();
+	psock = sk_psock(sk);
+	rcu_read_unlock();
+	if (psock)
+		return -EBUSY;
+
 	/* The TLS ulp is currently supported only for TCP sockets
 	 * in ESTABLISHED state.
 	 * Supporting sockets in LISTEN state will require us
-- 
2.52.0

Re: [PATCH] tls: reject attaching TLS to sockets already in sockmap

[Jiayuan Chen]

On 3/21/26 11:30 AM, Xingwang Xiang wrote:
> When a socket is first inserted into a sockmap with a verdict program,
> then TLS is enabled on that socket, the TLS strparser's saved_data_ready
> callback becomes sk_psock_verdict_data_ready(). This function calls
> tcp_read_skb() which drains ALL skbs from sk_receive_queue without
> updating tp->copied_seq when the BPF verdict is SK_PASS. This leaves
> tcp_inq() returning stale values, causing the TLS strparser to think
> data exists in the receive queue when it doesn't.
>
> The result is a WARN_ON_ONCE(!first) in tls_strp_load_anchor_with_queue()
> when tcp_recv_skb() returns NULL, and Use-After-Free when
> the strparser's frag_list points to skbs that have been unlinked and
> are now owned by the sockmap subsystem.
>
> While sk_psock_init() correctly checks inet_csk_has_ulp() to prevent
> inserting TLS sockets into sockmaps (blocking "forward order"), tls_init()
> does not check for an existing psock, allowing "reverse order" setup.
>
> Fix this by adding a check in tls_init() to reject sockets that already
> have a psock attached (i.e., are in a sockmap). This mirrors the


Hi Xingwang,

Thanks for the patch and the detailed analysis of the problem.

However, TLS is designed to work together with sockmap — the TLS 
send/receive paths
(tls_sw_sendmsg, tls_sw_recvmsg) extensively use sk_psock_get() to 
cooperate with
sockmap for verdict and redirection. Rejecting sockets that already have 
a psock
would break this intended usage.

Also, could you try running the sockmap_ktls selftest
(tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c) after applying 
your patch?

I believe it will fail, since that selftest specifically exercises TLS + 
sockmap
combined functionality.

That said, the bug you described is real and worth investigating. It 
would be very
helpful if you could add a reproducer for your scenario as a new test 
case in
sockmap_ktls.c. That would help us better understand the root cause and 
find a
proper fix that addresses the issue without breaking the TLS + sockmap
integration.

Also, pls use [PATCH net v?] or [PATCH bpf v?] (if you think it is 
related to bpf/sockmap).


Thanks,
Jiayuan

Re: [PATCH] tls: reject attaching TLS to sockets already in sockmap

[xw x]

Hi Jiayuan,

I apologize. I fixed it this way because during my exploitation, I
discovered that sk_psock_init checks for the existence of ULP in sk,
which led me to believe that disabling sk with TLS from being added to
sockmap was expected behavior, and I thought this fix might have the
least impact.

In fact, the other patch which I believe is a more fundamental
solution, is similar to CVE-2025-37756. In
`tls_strp_load_anchor_with_queue`,
`skb_shinfo(strp->anchor)->frag_list = first` acquires a reference to
an skb but doesn't own it. This causes a  dangling pointer when other
kernel components not specifically adapted to TLS (tcp_disconnect in
CVE-2025-37756 and bpt in that vuln) release TLS skbs.

I will try to add my test program to
tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c so that you can
test it and understand the root cause.

Thanks,
Xingwang




On Sat, Mar 21, 2026 at 5:02 PM Jiayuan Chen <mrpre@163.com> wrote:
>
>
> On 3/21/26 11:30 AM, Xingwang Xiang wrote:
> > When a socket is first inserted into a sockmap with a verdict program,
> > then TLS is enabled on that socket, the TLS strparser's saved_data_ready
> > callback becomes sk_psock_verdict_data_ready(). This function calls
> > tcp_read_skb() which drains ALL skbs from sk_receive_queue without
> > updating tp->copied_seq when the BPF verdict is SK_PASS. This leaves
> > tcp_inq() returning stale values, causing the TLS strparser to think
> > data exists in the receive queue when it doesn't.
> >
> > The result is a WARN_ON_ONCE(!first) in tls_strp_load_anchor_with_queue()
> > when tcp_recv_skb() returns NULL, and Use-After-Free when
> > the strparser's frag_list points to skbs that have been unlinked and
> > are now owned by the sockmap subsystem.
> >
> > While sk_psock_init() correctly checks inet_csk_has_ulp() to prevent
> > inserting TLS sockets into sockmaps (blocking "forward order"), tls_init()
> > does not check for an existing psock, allowing "reverse order" setup.
> >
> > Fix this by adding a check in tls_init() to reject sockets that already
> > have a psock attached (i.e., are in a sockmap). This mirrors the
>
>
> Hi Xingwang,
>
> Thanks for the patch and the detailed analysis of the problem.
>
> However, TLS is designed to work together with sockmap — the TLS
> send/receive paths
> (tls_sw_sendmsg, tls_sw_recvmsg) extensively use sk_psock_get() to
> cooperate with
> sockmap for verdict and redirection. Rejecting sockets that already have
> a psock
> would break this intended usage.
>
> Also, could you try running the sockmap_ktls selftest
> (tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c) after applying
> your patch?
>
> I believe it will fail, since that selftest specifically exercises TLS +
> sockmap
> combined functionality.
>
> That said, the bug you described is real and worth investigating. It
> would be very
> helpful if you could add a reproducer for your scenario as a new test
> case in
> sockmap_ktls.c. That would help us better understand the root cause and
> find a
> proper fix that addresses the issue without breaking the TLS + sockmap
> integration.
>
> Also, pls use [PATCH net v?] or [PATCH bpf v?] (if you think it is
> related to bpf/sockmap).
>
>
> Thanks,
> Jiayuan
>
>

Re: [PATCH] tls: reject attaching TLS to sockets already in sockmap

[Jakub Kicinski]

On Sat, 21 Mar 2026 17:47:07 +0800 xw x wrote:
> I apologize. I fixed it this way because during my exploitation, I
> discovered that sk_psock_init checks for the existence of ULP in sk,
> which led me to believe that disabling sk with TLS from being added to
> sockmap was expected behavior, and I thought this fix might have the
> least impact.
> 
> In fact, the other patch which I believe is a more fundamental
> solution, is similar to CVE-2025-37756. In
> `tls_strp_load_anchor_with_queue`,
> `skb_shinfo(strp->anchor)->frag_list = first` acquires a reference to
> an skb but doesn't own it. This causes a  dangling pointer when other
> kernel components not specifically adapted to TLS (tcp_disconnect in
> CVE-2025-37756 and bpt in that vuln) release TLS skbs.
> 
> I will try to add my test program to
> tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c so that you can
> test it and understand the root cause.

FWIW you can open a pull request against this repo, and it will run all
the sockmap+TLS tests for you: https://github.com/kernel-patches/bpf

reminder: please don't top post on the list