CVE-2026-74469 in Linux
Summary
by MITRE • 08/15/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability identified in the Linux kernel pertains to a critical flaw in the Stream Control Transmission Protocol implementation that could lead to memory corruption and potential denial of service conditions. This issue specifically affects the SCTP association management mechanism where the transport_count field, a 16-bit unsigned integer, is incremented for each new unique peer address added to an association. The fundamental problem arises from the lack of proper bounds checking when this counter approaches its maximum value of 65,536, creating a predictable overflow condition that can be exploited by malicious actors.
The technical flaw manifests in the sctp_assoc_add_peer() function which increments the transport_count without validating whether it has reached the maximum allowed value. When the counter reaches U16_MAX (65,535), the subsequent increment causes an arithmetic wraparound to zero, effectively resetting the counter. This overflow condition becomes particularly dangerous when combined with the SCTP sock_diag subsystem which relies on this transport_count value to pre-allocate memory for diagnostic payload structures. The system uses the transport_count to reserve INET_DIAG_PEERS payload space and subsequently copies sockaddr_storage entries for each address in the transport_addr_list, creating a direct correlation between the counter value and memory allocation decisions.
The operational impact of this vulnerability extends beyond simple resource exhaustion to potentially enable more sophisticated attack vectors. When the transport_count wraps around from 65,535 to zero, the diagnostic dump functionality attempts to reserve an empty payload while simultaneously writing 8 MiB of peer addresses past the allocated skb (socket buffer) tail. This memory corruption scenario can result in kernel memory corruption, leading to system instability, crashes, or potentially exploitable conditions that could allow privilege escalation. The vulnerability is particularly concerning because it occurs during legitimate network operations when multiple unique peer addresses are being added to an SCTP association, making it difficult to detect and mitigate through normal monitoring procedures.
This vulnerability aligns with CWE-190, Integer Overflow or Wraparound, which specifically addresses issues where integer arithmetic results in values that exceed the maximum representable value for the data type. The flaw also relates to ATT&CK technique T1499.004, Network Denial of Service, as it can be exploited to cause system instability through memory corruption. The mitigation strategy implemented involves adding a boundary check immediately after the existing peer lookup process, ensuring that no new unique peers are accepted when transport_count has reached U16_MAX. This approach maintains backward compatibility by allowing duplicate addresses to continue functioning normally while preventing the overflow condition from occurring at the point of maximum counter value. The fix ensures that duplicate address lookups continue to return existing transports rather than creating new ones when the limit has been reached, preserving system stability while maintaining proper SCTP association management behavior.
The resolution demonstrates a classic example of integer overflow protection mechanisms that should be implemented in kernel networking code where counters are used for memory allocation decisions. The vulnerability highlights the importance of considering wraparound conditions in systems where 16-bit counters control critical resource allocation functions, particularly in kernel space where such issues can lead to severe system instability and potential security implications. This fix reinforces the need for comprehensive bounds checking in all integer operations that affect memory management and resource allocation within kernel subsystems, particularly those handling network protocol implementations where multiple concurrent connections and peer addresses are common.