[SRU][RNJ][PATCH v2 0/1] CVE-2026-64564

[ChunAn Wu]

Buglink: https://ubuntu.com/security/CVE-2026-64564

[ Impact ]

An SCTP peer can send a specially crafted ASCONF chunk with an Address
Parameter and DEL-IP parameters that cause the kernel to free the transport
cached by the ASCONF while it is still in use. A subsequent wildcard DEL-IP
then dereferences and stores the dangling transport pointer, causing a
use-after-free and leaving the association without valid peer transports.
The issue requires SCTP ADD-IP support to be enabled and a crafted ASCONF
from an established SCTP peer.

[ Fix ]

Resolute:

Apply upstream commit 9b2854f86f0b ("sctp: don't free the ASCONF's own
transport in DEL-IP processing"), carried locally as 3c5ae7a890fc. It rejects
a DEL-IP targeting the transport against which the ASCONF chunk is being
processed. This preserves the cached transport until ASCONF processing
completes and prevents the wildcard DEL-IP path from reusing a freed
transport.

[ Test Case ]

The generated patch passes scripts/checkpatch.pl --strict. No runtime SCTP
ASCONF test was performed for this backport. The patch is a clean cherry-pick
of upstream commit 9b2854f86f0b ("sctp: don't free the ASCONF's own transport
in DEL-IP processing").

[ Regression Potential ]

The fix only rejects a DEL-IP that attempts to remove the transport against
which its ASCONF is being processed. If the check is incorrect, a legitimate
DEL-IP for that transport could be rejected with SCTP_ERROR_REQ_REFUSED, and
the peer would need to retry the address deletion through a different path.
Without the fix, a malicious or malformed ASCONF can trigger a use-after-free,
risking an SCTP association failure or kernel crash on systems accepting SCTP
ADD-IP traffic.

Jun Yang (1):
  sctp: don't free the ASCONF's own transport in DEL-IP processing

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

-- 
2.34.1