GHSA-jwjp-4649-v8jp

SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing

Published

2026-08-12

Modified

2026-08-12

Sources

github-advisory

Summary

## Summary `SctpSackChunk.ParseChunk` reads the `numGapAckBlocks` and `numDuplicateTSNs` fields (each up to 65535) directly from an attacker-controlled SCTP SACK chunk and loops that many times reading 4 bytes per iteration, with no validation of the counts against the chunk length or the receive buffer. A single crafted SACK chunk from a negotiated WebRTC peer forces reads past the end of the 262144-byte receive buffer, raising `IndexOutOfRangeException`, which is not caught by the recoverable handler and terminates the dedicated SCTP receive thread — permanently killing the SCTP association and all data channels. ## Root Cause `src/SIPSorcery/net/SCTP/Chunks/SctpSackChunk.cs`: - `ushort numGapAckBlocks = NetConvert.ParseUInt16(buffer, startPosn + 8);` (:141) - `ushort numDuplicateTSNs = NetConvert.ParseUInt16(buffer, startPosn + 10);` (:142) - gap-ack loop (:146) and duplicate-TSN loop (:154) index the buffer via `NetConvert.ParseUInt16/32` (`buffer[posn]`, no bounds check — `sys/Net/NetConvert.cs:30,41`). `SctpPacket.ParseChunks` (SctpPacket.cs:195-203) only validates `chunkLength >= 4` and `posn+chunkLength =4` and `posn+chunkLength 262144`; buffer is 262144 (`DEFAULT_ADVERTISED_RECEIVE_WINDOW`, SctpAssociation.cs:62). `numGapAckBlocks` alone suffices — the dup-TSN loop is not needed. - `DoReceive` catch split: recoverable `catch(ApplicationException)` at :345 (`continue`) vs generic `catch(Exception)` at :356 (`break`); `_receiveThread` started once at :176. #

Affected packages

Remediation: Upgrade to 10.0.14 or later.

References

• https://github.com/advisories/GHSA-jwjp-4649-v8jp