From: Jakub Kicinski <kuba@kernel.org>
To: xw x <v3rdant.xiang@gmail.com>
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>,
jakub@cloudflare.com, sd@queasysnail.net, davem@davemloft.net,
pabeni@redhat.com, horms@kernel.org, netdev@vger.kernel.org,
Jiayuan Chen <mrpre@163.com>,
Daniel Borkmann <daniel@iogearbox.net>,
john.fastabend@gmail.com, bpf@vger.kernel.org
Subject: Re: [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket
Date: Mon, 11 May 2026 19:06:44 -0700 [thread overview]
Message-ID: <20260511190644.23334e6d@kernel.org> (raw)
In-Reply-To: <CAFFJMPwtWZDrD0=hANXk2cdZGt2ArQEWROGRswKPyiZ+FrG1XQ@mail.gmail.com>
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.
next parent reply other threads:[~2026-05-12 2:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260511155210.32926-1-v3rdant.xiang@gmail.com>
[not found] ` <20260511161320.358cfaad@kernel.org>
[not found] ` <CAFFJMPzw8pcwX9g7iv3F=FpHQyovUgZZ28P7XfH3gmiay-JfpA@mail.gmail.com>
[not found] ` <CAFFJMPwtWZDrD0=hANXk2cdZGt2ArQEWROGRswKPyiZ+FrG1XQ@mail.gmail.com>
2026-05-12 2:06 ` Jakub Kicinski [this message]
2026-05-12 2:59 ` [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket Jiayuan Chen
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=20260511190644.23334e6d@kernel.org \
--to=kuba@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=jiayuan.chen@linux.dev \
--cc=john.fastabend@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox