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

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.

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

[Jiayuan Chen]

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.