CVE-2026-89476

A flaw in the Linux kernel's SCTP stream reconfiguration (RECONF) handling allows a duplicate response chunk to re-apply an already-processed ADD_OUT request while another parameter from the same cached chunk is still outstanding, rolling back the outbound stream count (stream->outcnt) twice and potentially causing it to underflow. An attacker triggers this by sending crafted or replayed SCTP RECONF responses to a host that is actively using SCTP stream reconfiguration; the impact is availability only (CVSS 7.5, A:H, no confidentiality or integrity impact), so the practical outcome is a crash or corruption of the SCTP stack and dropped connections. Affected systems are Linux machines with SCTP enabled and in active use — most commonly telecom signaling (SIGTRAN/Diameter-style) deployments — since ordinary TCP/UDP traffic never reaches this code path. No public proof-of-concept exists, the CVE is not on the CISA Known Exploited Vulnerabilities catalog, and no exploitation in the wild is known.

What to do: Apply kernel updates from your distribution as soon as it ships the SCTP RECONF outcnt fix (check the kernel/changelog for the 'sctp: fix stream->outcnt underflow on duplicate RECONF responses' commit) and reboot. If SCTP is not needed, blacklist the sctp kernel module and block IP protocol 132 at perimeter firewalls to remove exposure entirely. SCTP-based signaling operators should monitor for duplicate or anomalous RECONF chunks from peers.