From: Jun Yang <junvyyang@tencent.com>

sctp_process_asconf() caches the transport the ASCONF chunk is processed
against in asconf->transport (== chunk->transport, set once in sctp_rcv()).
For an ASCONF located through its Address Parameter by
__sctp_rcv_asconf_lookup(), that cached transport corresponds to the
Address Parameter, which need not be the packet's source address.

sctp_process_asconf_param() rejects a DEL-IP for the packet source address
(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport.
A single ASCONF can therefore carry, in order:

    [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and
calls sctp_assoc_rm_peer() on the transport that asconf->transport still
points at, freeing it (RCU-deferred). The following wildcard DEL-IP then
reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and
sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed
transport (->ipaddr, ->state) and plants the dangling pointer into
asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping
only the pointer that is no longer on the list, removes every real
transport, leaving the association with a transport_count of 0 and
primary_path/active_path pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed
against, mirroring the existing source-address guard, so the wildcard
branch can never reuse a freed transport.

Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter")
Cc: stable@kernel.org
Signed-off-by: Jun Yang <junvyyang@tencent.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
---
v3: return Request Refused instead of Request to Delete Source IP Address,
    as the protected transport need not be the packet's source address.
v2: add [net] subject prefix to target the net tree.

 net/sctp/sm_make_chunk.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 8adac9e0cd66..b14251214896 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3153,6 +3153,12 @@ static __be16 sctp_process_asconf_param(struct sctp_association *asoc,
 		if (!peer)
 			return SCTP_ERROR_DNS_FAILED;

+		/* Don't free asconf->transport; a later wildcard DEL-IP
+		 * parameter reuses it.
+		 */
+		if (peer == asconf->transport)
+			return SCTP_ERROR_REQ_REFUSED;
+
 		sctp_assoc_rm_peer(asoc, peer);
 		break;
 	case SCTP_PARAM_SET_PRIMARY:
--
2.55.0

On Tue, 21 Jul 2026 21:14:05 +0800 Jun Yang wrote:
> Acked-by: Xin Long <lucien.xin@gmail.com>

Could you point me to where Xin Long acked this?
I don't see the ack in replies to v1 or v2.

On Thu, Jul 23, 2026 at 10:29 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 21 Jul 2026 21:14:05 +0800 Jun Yang wrote:
> > Acked-by: Xin Long <lucien.xin@gmail.com>
>
> Could you point me to where Xin Long acked this?
> I don't see the ack in replies to v1 or v2.
Hi Jakub,

He initially sent the patch to security@kernel.org, and I asked him to
submit it to netdev with my Ack.

By the way, there's a question about whether patches for security fixes
should include the PoC in the patch/cover-letter when they're posted to
the netdev ML?

Thanks,

On Thu, 23 Jul 2026 11:33:27 -0400 Xin Long wrote:
> On Thu, Jul 23, 2026 at 10:29 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Tue, 21 Jul 2026 21:14:05 +0800 Jun Yang wrote:  
> > > Acked-by: Xin Long <lucien.xin@gmail.com>  
> >
> > Could you point me to where Xin Long acked this?
> > I don't see the ack in replies to v1 or v2.  
> 
> He initially sent the patch to security@kernel.org, and I asked him to
> submit it to netdev with my Ack.

Got it, thanks!

> By the way, there's a question about whether patches for security fixes
> should include the PoC in the patch/cover-letter when they're posted to
> the netdev ML?

Not sure if there's an official policy on this but IMHO they should be
easily accessible to reviewers / maintainers. If a frontier LLM can
generate an exploit for the problem based on the patch, hiding the
repro buys us nothing. And often the repro is useful during review.

For me an ideal submission would contain just a description of how the
bug was triggered in testing in the commit message, and a link to the
repro / PoC under the --- marker.