[PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket

[PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket

[Xingwang Xiang]

This series fixes a use-after-free triggered by configuring TLS RX on a
socket that is already inserted into a sockmap (the reverse of the order
that is already guarded against by tcp_bpf_check_ulp).

Patch 1 adds the symmetric check to do_tls_setsockopt_conf: if a psock
is already attached when TLS_RX is requested, return -EBUSY before any
strparser state is touched.

Patch 2 adds a regression test to the KTLS selftest suite that drives
the vulnerable setup and verifies the kernel either rejects the
combination or handles it correctly end-to-end.

Xingwang Xiang (2):
  net/tls: reject TLS_RX setsockopt on psock-owned sockets
  selftests: bpf: add test for KTLS+sockmap reverse-order UAF

 net/tls/tls_main.c                            |   9 ++
 .../selftests/bpf/prog_tests/sockmap_ktls.c   | 109 ++++++++++++++++++
 .../selftests/bpf/progs/test_sockmap_ktls.c   |  21 ++++
 3 files changed, 139 insertions(+)

-- 
2.54.0

[PATCH net v4 1/2] net/tls: reject TLS_RX setsockopt on psock-owned sockets

[Xingwang Xiang]

When a TCP socket is inserted into a sockmap before TLS RX is
configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready
as rx_ctx->saved_data_ready.  On data arrival tls_rx_msg_ready()
calls saved_data_ready(), which is sk_psock_verdict_data_ready().
That calls tcp_read_skb(), draining sk_receive_queue via
__skb_unlink() without advancing copied_seq, because SK_PASS through
sk_psock_verdict_recv() does not call tcp_eat_skb().

tls_strp_msg_load() then sees tcp_inq() >= full_len (stale), calls
tcp_recv_skb() on an empty queue, triggers WARN_ON_ONCE(!first), and
returns with rx_ctx->strp.anchor.frag_list still pointing at a
psock-owned (potentially freed) skb.  tls_decrypt_sg() subsequently
walks that frag_list, yielding a use-after-free.

The existing guard only covers the reverse order: a sockmap update
already fails with EBUSY when the socket has TLS ULP set
(tcp_bpf_check_ulp).  Add the symmetric check: if a psock is already
attached to the socket, reject setsockopt(TLS_RX) with EBUSY before
any strparser state is modified.

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

diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index fd39acf41..46cdd38ae 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -648,6 +648,15 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
 	if (sockptr_is_null(optval) || (optlen < sizeof(*crypto_info)))
 		return -EINVAL;
 
+	if (!tx) {
+		struct sk_psock *psock = sk_psock_get(sk);
+
+		if (psock) {
+			sk_psock_put(sk, psock);
+			return -EBUSY;
+		}
+	}
+
 	if (tx) {
 		crypto_ctx = &ctx->crypto_send;
 		alt_crypto_info = &ctx->crypto_recv.info;
-- 
2.54.0

[PATCH net v4 2/2] selftests: bpf: add test for KTLS+sockmap reverse-order UAF

[Xingwang Xiang]

Add a selftest that reproduces the use-after-free triggered when a TCP
socket is inserted into a sockmap *before* TLS RX is configured on it
(the reverse of the order that is already blocked by the kernel).

Vulnerable sequence:

  1. bpf_map_update_elem(sockmap, server_fd)
     -> sk->sk_data_ready = sk_psock_verdict_data_ready

  2. setsockopt(server_fd, SOL_TLS, TLS_RX, ...)
     -> tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as
        rx_ctx->saved_data_ready, then sets
        sk->sk_data_ready = tls_data_ready

When data arrives:
  tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready ->
  saved_data_ready() [= sk_psock_verdict_data_ready] ->
  tcp_read_skb() drains sk_receive_queue via __skb_unlink() without
  calling tcp_eat_skb(), so copied_seq is never advanced.

  tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls
  tcp_recv_skb() on an empty queue, hits WARN_ON_ONCE(!first), and
  returns with frag_list still pointing at the now psock-owned (or
  already freed) skb.  tls_decrypt_sg() subsequently walks that stale
  frag_list: a use-after-free.

The new BPF program (prog_skb_verdict_pass, sk_skb/verdict) returns
SK_PASS, which is the specific verdict that triggers the missing
tcp_eat_skb() call inside sk_psock_verdict_recv().

The test drives the full setup in the vulnerable order and then
attempts a send+recv.  After a correct fix the kernel either:

  (a) rejects setsockopt(TLS_RX) with EBUSY/EINVAL when the socket is
      already owned by a psock, or
  (b) completes the data transfer without corruption or kernel warnings.

Signed-off-by: Xingwang Xiang <v3rdant.xiang@gmail.com>
---
 .../selftests/bpf/prog_tests/sockmap_ktls.c   | 109 ++++++++++++++++++
 .../selftests/bpf/progs/test_sockmap_ktls.c   |  21 ++++
 2 files changed, 130 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c
index b87e7f39e..e71e6561b 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c
@@ -417,6 +417,113 @@ static void run_tests(int family, enum bpf_map_type map_type)
 	close(map);
 }
 
+/*
+ * Regression test for the KTLS + sockmap reverse-order frag_list UAF.
+ *
+ * Vulnerable sequence:
+ *   1. Insert receiver socket into sockmap (sets sk_data_ready =
+ *      sk_psock_verdict_data_ready)
+ *   2. Configure TLS RX on the same socket: tls_sw_strparser_arm() saves
+ *      sk_psock_verdict_data_ready as rx_ctx->saved_data_ready and replaces
+ *      sk_data_ready with tls_data_ready.
+ *
+ * When data arrives, tls_rx_msg_ready() calls saved_data_ready(), which is
+ * sk_psock_verdict_data_ready().  That drains sk_receive_queue via
+ * tcp_read_skb() / __skb_unlink() without advancing copied_seq.
+ * tls_strp_msg_load() then finds an empty queue while tcp_inq() is still
+ * non-zero, hits WARN_ON_ONCE(!first), and leaves a dangling frag_list
+ * pointer that tls_decrypt_sg() walks — a use-after-free.
+ *
+ * After the fix the kernel either:
+ *   (a) rejects setsockopt(TLS_RX) with EBUSY/EINVAL when the socket is
+ *       already owned by a psock, or
+ *   (b) correctly handles the data path so recv() returns the right data.
+ */
+static void test_sockmap_ktls_reverse_order_tls(int family, int sotype)
+{
+	struct tls12_crypto_info_aes_gcm_128 crypto_info = {};
+	char send_buf[] = "hello ktls sockmap reverse order";
+	char recv_buf[sizeof(send_buf)] = {};
+	struct test_sockmap_ktls *skel;
+	int c = -1, p = -1, zero = 0;
+	int prog_fd, map_fd;
+	ssize_t n;
+	int err;
+
+	skel = test_sockmap_ktls__open_and_load();
+	if (!ASSERT_TRUE(skel, "open_and_load"))
+		return;
+
+	err = create_pair(family, sotype, &c, &p);
+	if (!ASSERT_OK(err, "create_pair"))
+		goto out;
+
+	prog_fd = bpf_program__fd(skel->progs.prog_skb_verdict_pass);
+	map_fd = bpf_map__fd(skel->maps.sock_map_verdict);
+
+	err = bpf_prog_attach(prog_fd, map_fd, BPF_SK_SKB_VERDICT, 0);
+	if (!ASSERT_OK(err, "bpf_prog_attach sk_skb verdict"))
+		goto out;
+
+	/* Configure TLS TX on the sender (normal order, no sockmap) */
+	err = setsockopt(c, IPPROTO_TCP, TCP_ULP, "tls", strlen("tls"));
+	if (!ASSERT_OK(err, "setsockopt(TCP_ULP) client"))
+		goto out;
+
+	crypto_info.info.version = TLS_1_2_VERSION;
+	crypto_info.info.cipher_type = TLS_CIPHER_AES_GCM_128;
+	memset(crypto_info.key, 0x01, sizeof(crypto_info.key));
+	memset(crypto_info.salt, 0x02, sizeof(crypto_info.salt));
+
+	err = setsockopt(c, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info));
+	if (!ASSERT_OK(err, "setsockopt(TLS_TX)"))
+		goto out;
+
+	/* Insert receiver into sockmap BEFORE TLS RX — the vulnerable ordering */
+	err = bpf_map_update_elem(map_fd, &zero, &p, BPF_NOEXIST);
+	if (!ASSERT_OK(err, "bpf_map_update_elem server"))
+		goto out;
+
+	/* Attempt TLS RX setup AFTER sockmap insertion */
+	err = setsockopt(p, IPPROTO_TCP, TCP_ULP, "tls", strlen("tls"));
+	if (err) {
+		/* Kernel correctly rejected TLS ULP on a psock-owned socket */
+		ASSERT_TRUE(errno == EINVAL || errno == EBUSY,
+			    "expected EINVAL or EBUSY for TCP_ULP on sockmap socket");
+		goto out;
+	}
+
+	err = setsockopt(p, SOL_TLS, TLS_RX, &crypto_info, sizeof(crypto_info));
+	if (err) {
+		/* Kernel correctly rejected TLS RX after sockmap insertion */
+		ASSERT_TRUE(errno == EINVAL || errno == EBUSY || errno == EOPNOTSUPP,
+			    "expected rejection of TLS_RX on sockmap socket");
+		goto out;
+	}
+
+	/*
+	 * Setup was allowed — verify data transfer is correct.
+	 * A buggy kernel hits WARN_ON_ONCE in tls_strp_load_anchor_with_queue
+	 * and may UAF in tls_decrypt_sg when walking the stale frag_list.
+	 */
+	n = send(c, send_buf, sizeof(send_buf), 0);
+	if (!ASSERT_EQ(n, (ssize_t)sizeof(send_buf), "send"))
+		goto out;
+
+	n = recv_timeout(p, recv_buf, sizeof(recv_buf), 0, 5);
+	if (!ASSERT_EQ(n, (ssize_t)sizeof(send_buf), "recv"))
+		goto out;
+
+	ASSERT_OK(memcmp(send_buf, recv_buf, sizeof(send_buf)), "data integrity");
+
+out:
+	if (c != -1)
+		close(c);
+	if (p != -1)
+		close(p);
+	test_sockmap_ktls__destroy(skel);
+}
+
 static void run_ktls_test(int family, int sotype)
 {
 	if (test__start_subtest("tls simple offload"))
@@ -429,6 +536,8 @@ static void run_ktls_test(int family, int sotype)
 		test_sockmap_ktls_tx_no_buf(family, sotype, true);
 	if (test__start_subtest("tls tx with pop"))
 		test_sockmap_ktls_tx_pop(family, sotype);
+	if (test__start_subtest("tls rx after sockmap insert"))
+		test_sockmap_ktls_reverse_order_tls(family, sotype);
 }
 
 void test_sockmap_ktls(void)
diff --git a/tools/testing/selftests/bpf/progs/test_sockmap_ktls.c b/tools/testing/selftests/bpf/progs/test_sockmap_ktls.c
index 83df4919c..facafeaf4 100644
--- a/tools/testing/selftests/bpf/progs/test_sockmap_ktls.c
+++ b/tools/testing/selftests/bpf/progs/test_sockmap_ktls.c
@@ -17,6 +17,13 @@ struct {
 	__type(value, int);
 } sock_map SEC(".maps");
 
+struct {
+	__uint(type, BPF_MAP_TYPE_SOCKMAP);
+	__uint(max_entries, 2);
+	__type(key, int);
+	__type(value, int);
+} sock_map_verdict SEC(".maps");
+
 SEC("sk_msg")
 int prog_sk_policy(struct sk_msg_md *msg)
 {
@@ -38,3 +45,17 @@ int prog_sk_policy_redir(struct sk_msg_md *msg)
 	bpf_msg_apply_bytes(msg, apply_bytes);
 	return bpf_msg_redirect_map(msg, &sock_map, two, 0);
 }
+
+/*
+ * Verdict program for the reverse-order TLS/sockmap regression test.
+ * Returns SK_PASS so tcp_read_skb() drains the receive queue via
+ * sk_psock_verdict_recv() without calling tcp_eat_skb(), which is
+ * the precondition for the KTLS strparser frag_list UAF.
+ */
+SEC("sk_skb/verdict")
+int prog_skb_verdict_pass(struct __sk_buff *skb)
+{
+	return SK_PASS;
+}
+
+char _license[] SEC("license") = "GPL";
-- 
2.54.0

Re: [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket

[Jakub Kicinski]

On Tue, 12 May 2026 00:52:07 +0900 Xingwang Xiang wrote:
> This series fixes a use-after-free triggered by configuring TLS RX on a
> socket that is already inserted into a sockmap (the reverse of the order
> that is already guarded against by tcp_bpf_check_ulp).

Just to check - how much of this code or the patch do you understand?

Re: [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket

[xw x]

On Tue, May 12, 2026 at 7:13 AM Jakub Kicinski <kuba@kernel.org> wrote:
> Just to check - how much of this code or the patch do you understand?

I think I understand the root cause. Based on Jiayuan Chen’s
feedback—that we should deny TLS_RX attachments for sockets already in
a sockmap—I've prepared my patch to do exactly that. Do you see any
issues with this approach?

On Mon, May 11, 2026 at 10:13 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> I think sockmap + TLS_RX has no useful semantics(fix me if i'm wrong).
> sk_skb sees ciphertext and the TLS keys are pinned to this socket, so
> redirect is meaningless. And both sides racing on sk_receive_queue is
> what produces the UAF.
>
> The fix should be to reject TLS_RX when the socket is already in a sockmap.
>
> Note TLS_TX + sockmap remains useful and unaffected.

Additionally, my changes seem to trigger a failure in the
test_sockmap_ktls_tx_no_buf test. Specifically, it attempts to set
TLS_RX on a socket that is already in a sockmap within
init_ktls_pairs. Since I didn't author this test, I’m not sure if the
TLS_RX requirement there is essential for what’s being tested. I could
use some guidance on whether the test should be updated or if my
approach needs adjustment.

Re: [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket

[Jakub Kicinski]

On Tue, 12 May 2026 08:10:03 +0800 xw x wrote:
> On Tue, May 12, 2026 at 7:13 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > Just to check - how much of this code or the patch do you understand?  
> 
> I think I understand the root cause. Based on Jiayuan Chen’s
> feedback—that we should deny TLS_RX attachments for sockets already in
> a sockmap—I've prepared my patch to do exactly that. Do you see any
> issues with this approach?

I mean.. I have no proof that real users of the TLS + sockmap exist
but I thought that they did.

> On Mon, May 11, 2026 at 10:13 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
> >
> > I think sockmap + TLS_RX has no useful semantics(fix me if i'm wrong).
> > sk_skb sees ciphertext and the TLS keys are pinned to this socket, so
> > redirect is meaningless. And both sides racing on sk_receive_queue is
> > what produces the UAF.
> >
> > The fix should be to reject TLS_RX when the socket is already in a sockmap.
> >
> > Note TLS_TX + sockmap remains useful and unaffected.  
> 
> Additionally, my changes seem to trigger a failure in the
> test_sockmap_ktls_tx_no_buf test. Specifically, it attempts to set
> TLS_RX on a socket that is already in a sockmap within
> init_ktls_pairs. Since I didn't author this test, I’m not sure if the
> TLS_RX requirement there is essential for what’s being tested. I could
> use some guidance on whether the test should be updated or if my
> approach needs adjustment.

Your report is narrowly for the verdict-only case in sockmap.
But you're banning all TLS + sockmap.

I think we need a similar workaround in sk_psock_verdict_data_ready()
as what e91de6afa81c ("bpf: Fix running sk_skb program types with ktls")
added for the full sockmap path. Or selectively ban the verdict only
format. But that feels a little less clean. Dunno.

Please, do not repost this until 24h have passed. Maybe Jiayuan Chen
or sockmap folks (who you apparently didn't CC?) have some comments.