Linux Kernel SCTP DEL-IP Processing Frees the Transport Cached on the ASCONF Chunk Itself, Triggering Use-After-Free on the Chunk's Own Transport Pointer

Status: NEW  |  Advisory ID: CVE-2026-64564

Key Details

What to Know

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. (NVD)

References