CVE-2026-74586: sctp: clear new_transport when removing a peer
In the Linux kernel, the following vulnerability has been resolved:
sctp: clear newtransport when removing a peer
sctpprocessasconfparam() stores a newly added peer transport in asoc->newtransport. After all parameters in the ASCONF chunk have been processed, sctpsfdoasconf() uses this pointer to send a HEARTBEAT to the new transport.
An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctpassocdelnonprimarypeers(). The removal does not clear asoc->newtransport, leaving it pointing to the removed transport.
sctpsfdoasconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, srcoutofasocok keeps this HEARTBEAT on controlchunklist. After the transport is freed by RCU, a successful ASCONFACK for the replacement address releases the queued HEARTBEAT and sctpoutqselecttransport() reads the freed transport's state.
The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel:
BUG: KASAN: slab-use-after-free in sctpoutqselecttransport Read of size 4 at addr ffff88800b9bd95c by task python3/197
Call Trace: sctpoutqselecttransport+0x549/0x8b0 [sctp] sctpoutqflush+0x306/0x2c60 [sctp] sctptransportimmediatertx+0xaf/0x260 [sctp] sctpprocessasconfack+0xa48/0xf70 [sctp]
Allocated by task 197: sctptransportnew+0x68/0x650 [sctp] sctpassocaddpeer+0x258/0x12a0 [sctp] sctpprocessasconf+0x5e9/0x1090 [sctp]
Last potentially related work creation: callrcucommon.constprop.0+0x77/0xb70 sctpassocdelnonprimarypeers+0x7c/0xd0 [sctp] sctpprocessasconf+0xd9c/0x1090 [sctp]
The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops.
Clear newtransport when its peer is removed, before it can be used to create the HEARTBEAT.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What would an attacker need to send to trigger the vulnerable state?
The attacker must be a remote SCTP peer able to send an authenticated ASCONF chunk. The chunk must add a peer transport and then remove that newly added transport using a wildcard DEL-IP parameter in the same ASCONF chunk.
What conditions are needed for the use-after-free to be reached?
The problematic HEARTBEAT is retained on the control chunk list during local address replacement. After the removed transport is freed by RCU, a successful ASCONF_ACK for the replacement address can release that queued HEARTBEAT, causing SCTP transport selection to read the freed transport state.
How can I determine whether a system may be exposed?
Exposure requires Linux kernel SCTP associations that accept authenticated ASCONF operations from remote peers, along with address-configuration activity matching the described add/delete and local address replacement sequence. The provided information does not identify affected kernel versions or a configuration-only workaround.