CRITICAL Introduced in 2.6.12
sctp Transport UAF
CVE-2026-89478
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
KernelScan AI8.1HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.
02KernelScan AI Analysis
Risk summary
An authenticated SCTP peer can exploit a race window to trigger a use-after-free on a transport object, leading to kernel memory corruption. The attack is network-reachable and requires no OS-level privileges, only an established SCTP association. Systems processing SCTP traffic from untrusted or partially trusted peers are at risk of kernel-level compromise or denial of service.
Vulnerability analysis
When an SCTP packet arrives, the kernel looks up the transport for the chunk and saves the reference, but between that lookup and actual processing an authenticated peer can send a request that removes and frees that transport. If a data chunk arrives during this window, it briefly ties the removed transport back into the association; after the packet finishes, the transport is freed, but a later acknowledgment message still references the stale transport, causing the kernel to read freed memory when preparing the reply. The fix discards any chunk whose transport has already been removed before processing begins, at a point where the network receive paths are properly synchronized, so the check is safe and the peer simply retransmits. An authenticated SCTP peer on the network can trigger this by sending a transport-removal request followed by a data chunk within a tight race window; no local access or OS-level privileges are required.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| mainline | 2.6.12 | 7.3-rc1 | 03a9d10ecf71 |
| 6.1 | 2.6.12 | 6.1.188 | 0422b092a3d4 |
| 5.10 | 2.6.12 | 5.10.270 | 3fc072e7cb4a |
| 6.18 | 2.6.12 | 6.18.50 | 1035bdef1efb |
| 7.2 | 2.6.12 | 7.2.4 | 3537961df216 |
| 6.12 | 2.6.12 | 6.12.109 | c6c86a5e62a4 |
| 5.15 | 2.6.12 | 5.15.221 | d7cb5ad83209 |
| 6.6 | 2.6.12 | 6.6.157 | 928fd7920ba3 |