Description

In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-15T13:17:51.623Z",
  "pubdate": "2026-08-15T13:17:51.623Z",
  "executiveSummary": "An integer overflow vulnerability exists in the Stream Control Transmission Protocol (SCTP) subsystem of the Linux kernel, specifically within the peer transport tracking mechanism handled by sctp_assoc_add_peer().\nThe vulnerability is caused by an uncontrolled increment of a 16-bit transport_count variable when adding new unique peers, which wraps around to zero upon reaching 65,536 entries.\nWhen exploited via SCTP sock_diag diagnostic dumps, the integer wrap causes the system to reserve an empty INET_DIAG_PEERS payload while attempting to write a massive amount of peer addresses past the socket buffer (skb) tail.\nThis leads to severe memory corruption, potentially resulting in kernel panics, denial of service, or arbitrary memory overwrite conditions.\nAttackers with network access capable of establishing SCTP associations and triggering sock_diag operations can exploit this vulnerability.\nThe risk is mitigated by properly validating transport counts against U16_MAX limits to prevent arithmetic overflow during peer addition.",
  "technicalDetails": "The vulnerability resides in the Linux kernel SCTP subsystem, specifically affecting the association transport tracking logic in sctp_assoc_add_peer().\nThe root cause is an integer overflow in the 16-bit transport_count member of the SCTP association structure. Every time a new unique peer transport is added to an association via sctp_assoc_add_peer(), transport_count is incremented. Because the variable is 16-bit, adding the 65,536th transport wraps the count back to zero.\nThe vulnerability is triggered during SCTP sock_diag operations. SCTP sock_diag utilizes transport_count to calculate and reserve the INET_DIAG_PEERS payload size before copying one sockaddr_storage structure for every entry present in the transport_addr_list.\nFollowing an integer wrap, a diagnostic dump incorrectly calculates the required allocation size, resulting in the reservation of an empty payload buffer. Despite the insufficient buffer reservation, the routine proceeds to write approximately 8 MiB of peer addresses directly past the socket buffer (skb) tail.\nThe attack flow requires an actor to establish an SCTP association and provision or trigger the registration of 65,536 unique peers to force the 16-bit counter wraparound. Subsequently, invoking or triggering an SCTP sock_diag diagnostic dump on the affected socket causes the out-of-bounds write via the mismatched payload size and address copy loop.\nThe vulnerable component is the SCTP network subsystem, specifically the association peer management and sock_diag interface handling functions. No specific authentication or high-level privileges are explicitly detailed beyond the capability to interact with the SCTP stack and trigger diagnostic interfaces, typically exposing network and local attack surfaces depending on system configurations.\nPost-exploitation impact includes severe kernel memory corruption, out-of-bounds writes into kernel heap or skb allocations, and subsequent denial of service via kernel panics or system instability."
}