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

From: Greg Kroah-Hartman <[email protected]>

Description
===========

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

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

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.

The Linux kernel CVE team has assigned CVE-2026-64564 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.25 with commit 42e30bf3463cd37d73839376662cb79b4d5c416c and fixed in 6.6.148 with commit fedeb4468987bcaff85fe3061de5ae052d414740
	Issue introduced in 2.6.25 with commit 42e30bf3463cd37d73839376662cb79b4d5c416c and fixed in 6.12.101 with commit 74e8f3e7114f0e26d1b2c4c048044db9fcc27603
	Issue introduced in 2.6.25 with commit 42e30bf3463cd37d73839376662cb79b4d5c416c and fixed in 6.18.42 with commit 85aca407c560aba81b5ce9d3d6cf94c74077d19b
	Issue introduced in 2.6.25 with commit 42e30bf3463cd37d73839376662cb79b4d5c416c and fixed in 7.1.6 with commit d136b29bf91dd8e3161281b87de597b7311d9462
	Issue introduced in 2.6.25 with commit 42e30bf3463cd37d73839376662cb79b4d5c416c and fixed in 7.2-rc5 with commit 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64564
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/sctp/sm_make_chunk.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/fedeb4468987bcaff85fe3061de5ae052d414740
	https://git.kernel.org/stable/c/74e8f3e7114f0e26d1b2c4c048044db9fcc27603
	https://git.kernel.org/stable/c/85aca407c560aba81b5ce9d3d6cf94c74077d19b
	https://git.kernel.org/stable/c/d136b29bf91dd8e3161281b87de597b7311d9462
	https://git.kernel.org/stable/c/9b2854f86f0b56e9027d68e7a3fc909d1a9b566f