Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:29.207Z",
  "pubdate": "2026-09-11T20:19:29.207Z",
  "executiveSummary": "This vulnerability is a Use-After-Free (UAF) flaw within the Linux kernel's SCTP (Stream Control Transmission Protocol) implementation. The issue arises due to a race condition occurring when a transport object is removed from an association while a packet is still being processed or queued.\nThe vulnerability allows an authenticated remote attacker to trigger a memory corruption scenario by sending an ASCONF DEL-IP chunk, which deletes a transport while it is still referenced by incoming data chunks. This leads to the kernel performing operations on a freed transport object.\nThe impact includes potential kernel memory corruption, system instability, or denial-of-service (DoS) conditions through kernel panics. Exploitation requires the attacker to have an established SCTP association and the ability to send valid, authenticated SCTP control chunks.\nThis vulnerability affects the SCTP subsystem in the Linux kernel. The risk is significant as it involves complex concurrency issues within the network stack, potentially allowing for arbitrary code execution if the memory reclamation is precisely manipulated.",
  "technicalDetails": "The root cause of this vulnerability is an improper synchronization between the SCTP packet processing path and the removal of transport objects. In the SCTP stack, sctp_rcv() identifies the transport associated with an incoming packet and stores this reference in chunk->transport. This reference is intended to ensure the transport object remains valid during packet processing.\nHowever, an authenticated ASCONF DEL-IP chunk can trigger sctp_assoc_rm_peer(), which removes the transport from the association and invokes sctp_transport_free(). This operation marks the transport as dead and releases the association's reference to it. A race condition exists because packets already residing in the socket backlog, or those that have completed lookup before acquiring the bh_lock_sock(), continue to reference the now-freed or marked-dead transport object.\nThe exploitation flow proceeds as follows: First, an attacker establishes an SCTP association. Second, the attacker sends a legitimate DATA chunk simultaneously with an ASCONF DEL-IP command. The DATA chunk may place the soon-to-be-freed transport into asoc->peer.last_data_from. Once the processing of the DATA chunk completes, the reference to the transport is dropped, and the transport is freed via RCU (Read-Copy-Update).\nSubsequently, when the system initiates a delayed SACK, the kernel calls sctp_outq_select_transport(), which attempts to read the state of the now-freed transport. Since the memory associated with the transport has been deallocated or repurposed, this results in a Use-After-Free condition. The kernel dereferences a stale pointer, which can lead to unpredictable behavior, memory corruption, or a system crash.\nThe vulnerable component is the SCTP transport management logic within the Linux kernel. The issue persists because the socket backlog processing does not adequately validate the liveness of the transport object prior to consumption. By forcing the kernel to re-access a freed memory region, an attacker can manipulate kernel state. The mitigation involves checking the validity of the transport object within sctp_inq_push() to ensure that packets targeting dead transports are dropped before they are processed by the protocol stack."
}