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/[email protected]/
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.
