* Re: [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket [not found] ` <CAFFJMPwtWZDrD0=hANXk2cdZGt2ArQEWROGRswKPyiZ+FrG1XQ@mail.gmail.com> @ 2026-05-12 2:06 ` Jakub Kicinski 2026-05-12 2:59 ` Jiayuan Chen 0 siblings, 1 reply; 2+ messages in thread From: Jakub Kicinski @ 2026-05-12 2:06 UTC (permalink / raw) To: xw x Cc: Jiayuan Chen, jakub, sd, davem, pabeni, horms, netdev, Jiayuan Chen, Daniel Borkmann, john.fastabend, bpf 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. ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket 2026-05-12 2:06 ` [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket Jakub Kicinski @ 2026-05-12 2:59 ` Jiayuan Chen 0 siblings, 0 replies; 2+ messages in thread From: Jiayuan Chen @ 2026-05-12 2:59 UTC (permalink / raw) To: Jakub Kicinski, xw x Cc: jakub, sd, davem, pabeni, horms, netdev, Jiayuan Chen, Daniel Borkmann, john.fastabend, bpf On 5/12/26 10:06 AM, Jakub Kicinski wrote: > 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. Sorry, my earlier advice was wrong on this point. TLS_RX + sockmap is intentional. And there are public discussions about combination of KTLS with SOCKMAP, e.g. https://lpc.events/event/2/contributions/105/attachments/103/126/ktls_bpf.pdf >> 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 Agreed, sk_psock_verdict_data_ready should process tls like sk_psock_strp_data_ready. > 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. ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-12 2:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 ` [PATCH net v4 0/2] net/tls: fix UAF when TLS_RX is set on sockmap socket Jakub Kicinski
2026-05-12 2:59 ` Jiayuan Chen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox