netdev - Re: [net-next,v5,09/11] net: sctp: convert sctp_v{4,6}

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260118003611.1042386-1-kuba@kernel.org>
Date: Sat, 17 Jan 2026 16:36:11 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: mmietus97@...oo.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	netdev@...r.kernel.org,
	sd@...asysnail.net,
	Jason@...c4.com
Subject: Re: [net-next,v5,09/11] net: sctp: convert sctp_v{4,6}_xmit to use a noref dst when possible

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: sctp: convert sctp_v{4,6}_xmit to use a noref dst when possible

This patch removes the dst_clone() at function entry and dst_release() in
the encap path, aiming to reduce refcount overhead when sending SCTP packets
via UDP encapsulation. The non-encap path now clones dst inside skb_dst_set.

> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index 38fd1cf3148f..8c28441009fa 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c

[ ... ]

> @@ -264,7 +264,6 @@ static int sctp_v6_xmit(struct sk_buff *skb, struct sctp_transport *t)
>  	udp_tunnel6_xmit_skb(dst, sk, skb, NULL, &fl6->saddr, &fl6->daddr,
>  			     tclass, ip6_dst_hoplimit(dst), label,
>  			     sctp_sk(sk)->udp_port, t->encap_port, false, 0);
> -	dst_release(dst);
>  	return 0;
>  }

The encap path passes dst to udp_tunnel6_xmit_skb() which internally calls
skb_dst_set_noref(). This function has:

    WARN_ON(!rcu_read_lock_held() && !rcu_read_lock_bh_held());

Looking at the callers, sctp_outq_flush_transports() does:

    rcu_read_unlock();
    error = sctp_packet_transmit(packet, ctx->gfp);

The RCU read lock is explicitly dropped before calling into the transmit
path. Will this trigger the WARN_ON in skb_dst_set_noref() for every
SCTP-over-UDP packet?

> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index ff18ed0a65ff..8a00bb0a8ae5 100644

[ ... ]

> @@ -1074,7 +1074,6 @@ static inline int sctp_v4_xmit(struct sk_buff *skb, struct sctp_transport *t)
>  			    fl4->daddr, dscp, ip4_dst_hoplimit(dst), df,
>  			    sctp_sk(sk)->udp_port, t->encap_port, false, false,
>  			    0);
> -	dst_release(dst);
>  	return 0;
>  }

Same question for the IPv4 path - udp_tunnel_xmit_skb() calls iptunnel_xmit()
which also uses skb_dst_set_noref(). Without RCU read lock held by the caller,
does this path also trigger the WARN_ON?