CVE-2026-64564

In the Linux kernel, the following vulnerability has been resolved:

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctpprocessasconf() 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

_sctprcvasconflookup(), that cached transport corresponds to the

Address Parameter, which need not be the packet's source address.

sctpprocessasconf_param() rejects a DEL-IP for the packet source address

(ADDIP D8, SCTPERRORDELSRCIP), 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 sctpassocrm_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 sctpassocset_primary() and

sctpassocdelnonprimarypeers(): set_primary() dereferences the freed

transport (->ipaddr, ->state) and plants the dangling pointer into

asoc->peer.primarypath / activepath, and delnonprimarypeers(), 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

primarypath/activepath 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.