From: Jakub Kicinski <kuba@kernel.org>
To: xw x <v3rdant.xiang@gmail.com>
Cc: Jiayuan Chen <mrpre@163.com>,
jakub@cloudflare.com, sd@queasysnail.net, davem@davemloft.net,
pabeni@redhat.com, horms@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] tls: reject attaching TLS to sockets already in sockmap
Date: Sat, 21 Mar 2026 07:41:55 -0700 [thread overview]
Message-ID: <20260321074155.6fdb79dc@kernel.org> (raw)
In-Reply-To: <CAFFJMPyDpKwW9O127JkS1B3bgGGzWPpiw5MqFEbGB6Qpq0nsVQ@mail.gmail.com>
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
next prev parent reply other threads:[~2026-03-21 14:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 3:30 [PATCH] tls: reject attaching TLS to sockets already in sockmap Xingwang Xiang
2026-03-21 9:01 ` Jiayuan Chen
2026-03-21 9:47 ` xw x
2026-03-21 14:41 ` Jakub Kicinski [this message]
2026-05-11 12:51 ` xw x
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260321074155.6fdb79dc@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=mrpre@163.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=v3rdant.xiang@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.