From: "Daniel Zahka" <daniel.zahka@gmail.com>
To: <netdev-bot+sashiko@kernel.org>, <daniel.zahka@gmail.com>
Cc: <edumazet@google.com>, <ncardwell@google.com>,
<kuniyu@google.com>, <davem@davemloft.net>, <kuba@kernel.org>,
<pabeni@redhat.com>, <horms@kernel.org>,
<willemdebruijn.kernel@gmail.com>, <andrew+netdev@lunn.ch>,
<shuah@kernel.org>, <willemb@google.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH net 1/2] net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
Date: Tue, 15 Sep 2026 15:17:52 -0400 [thread overview]
Message-ID: <DLG4RGGCZ776.1UU67KP7TWDAH@gmail.com> (raw)
In-Reply-To: <178917294180.219967.2431474539892551274@kernel.org>
On Fri Sep 11, 2026 at 8:29 PM EDT, netdev-bot+sashiko wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>
> - [Medium] The new mutual-exclusion gate keys off
> `sk->sk_validate_xmit_skb`, a function pointer that is inherited…
>
> --
>
> net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
>
> This adds a mutual exclusion gate so that a socket cannot carry both PSP
> state and a TCP ULP, since the two conflict over skb->decrypted and
> sk->sk_validate_xmit_skb(). The gate is applied in __tcp_set_ulp() and in
> psp_sock_assoc_set_rx().
>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 51185222aac29..ba5e5092f192c 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -2312,6 +2312,17 @@ static inline void sk_gso_disable(struct sock *sk)
>> sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
>> }
>>
>> +static inline bool sk_has_validate_xmit_skb(const struct sock *sk)
>> +{
>> +#ifdef CONFIG_SOCK_VALIDATE_XMIT
>> + return !!sk->sk_validate_xmit_skb;
>> +#else
>> + return false;
>> +#endif
>> +}
>
> [Severity: Medium]
> Is sk_validate_xmit_skb a reliable indicator of live per-socket state here?
> The field sits after sk_dontcopy_end in struct sock, so sock_copy() copies
> it verbatim into a cloned socket, and neither sk_clone() nor
> inet_csk_clone_lock() resets it. By contrast, sk_clone() does explicitly
> clear the PSP association:
>
> net/core/sock.c:sk_clone() {
> sock_copy(newsk, sk);
> ...
> #if IS_ENABLED(CONFIG_INET_PSP)
> RCU_INIT_POINTER(newsk->psp_assoc, NULL);
> #endif
>
> So a socket accepted from a listener that had PSP Tx state installed ends up
> with sk_validate_xmit_skb == psp_validate_xmit while psp_assoc == NULL, and
> sk_has_validate_xmit_skb() then reports true for a child that has neither a
> PSP association nor a ULP.
>
Sorry, I started a response based on viewing this report in the clashiko
web app, but then realized after I had sent it that I had received the
report in email form. For the record my response is here:
https://lore.kernel.org/netdev/DLCXDVPGGC8M.11EBKPBY2KNVP@gmail.com/
So, is this a blocker to merge this as is? I could drop the check on
sk->sk_validtate_xmit_sbk to appease sashiko, but in my opinion this
makes the patch worse. My ultimate goal is to defeature psp assoc
operations on non TCP_ESTABLISHED sockets in a way similar to tls ulp.
next prev parent reply other threads:[~2026-09-15 19:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 23:46 [PATCH net 0/2] " Daniel Zahka
2026-09-10 23:46 ` [PATCH net 1/2] " Daniel Zahka
2026-09-12 0:29 ` netdev-bot+sashiko
2026-09-15 19:17 ` Daniel Zahka [this message]
2026-09-12 0:53 ` Daniel Zahka
2026-09-10 23:46 ` [PATCH net 2/2] selftests: drv-net: psp: test PSP and TCP ULP mutual exclusion Daniel Zahka
2026-09-11 10:57 ` Daniel Zahka
2026-09-11 20:00 ` Matthieu Baerts
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=DLG4RGGCZ776.1UU67KP7TWDAH@gmail.com \
--to=daniel.zahka@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@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
all inboxes | Powered by JetHome®