netdev - Re: [BUG] net/tls: UAF and BUG_ON via tcp_recvmsg/tcp_zerocopy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250806104746.0937caae@kernel.org>
Date: Wed, 6 Aug 2025 10:47:46 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Savy <savy@...t3mfailure.io>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "will@...lsroot.io"
 <will@...lsroot.io>, "borisp@...dia.com" <borisp@...dia.com>,
 "john.fastabend@...il.com" <john.fastabend@...il.com>,
 "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
 <edumazet@...gle.com>, "pabeni@...hat.com" <pabeni@...hat.com>,
 "horms@...nel.org" <horms@...nel.org>
Subject: Re: [BUG] net/tls: UAF and BUG_ON via
 tcp_recvmsg/tcp_zerocopy_receive

On Tue, 05 Aug 2025 16:30:37 +0000 Savy wrote:
> This UAF read can probably be transformed into a privilege escalation, 
> as the UAF read can be turned into a UAF write if the anchor undergoes the clone path.
> However, the conditions for that is pretty restrictive, 
> and may require features such as TLS hardware offload for us to hit such paths.
> 
> For the getsockopt(TCP_ZEROCOPY_RECEIVE) version of the bug, 
> we suggest the following check to fix the issue, as the SOCK_SUPPORT_ZC bit 
> is already cleared in __tcp_set_ulp() [2]:
> 
> static int tcp_zerocopy_receive(struct sock *sk,
>                 struct tcp_zerocopy_receive *zc,
>                 struct scm_timestamping_internal *tss)
> {
>     // [...]
> 
> +    /* ZC support has been cleared by ULP */
> +    if (!test_bit(SOCK_SUPPORT_ZC, &sk->sk_socket->flags))
> +        return -EOPNOTSUPP;
> 
>     // [...]
> }
> 
> For the tcp_recvmsg() version, we could check if there are any processes
> waiting for data on the socket before installing the ULP.

Thanks for the high quality bug report! I think that we're better off
checking if the copied_seq moved since we looked at the queue.
It should cover all cases at once. I'll share the proposed fix soon.