CVE-2026-119299

gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.

gopacket: SCTP chunk sub-decoder out-of-bounds panics on crafted segments

Summary

gopacket decodes SCTP (IP protocol 132) by walking the chunk chain through per-chunk-type decoder functions (decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, in layers/sctp.go). Each of these reads fixed-size header fields and runs count-driven loops without validating the chunk's declared length against the minimums those reads require. A single crafted SCTP segment causes a runtime panic (out-of-bounds slice read, or inverted slice from unsigned length arithmetic) on any decode path that does not install gopacket's per-packet panic recovery (gopacket.DecodeOptions.SkipDecodeRecovery: true); with the default API the same input degrades to a per-packet decode error.

The defect is present in every released version through v1.7.1 and at current master (18c5805). It is the SCTP component named - but not remediated - in CVE-2026-65819 (GHSA-8mcr-459q-5mx2, "Multiple layer decoders panic …", patched per advisory metadata in v1.7.1). The v1.7.1 hardening commit b772f56 ("layers:various: add protocol decoder length checks (#163)") added generic bounds to the chunk dispatcher and decodeSCTPChunk, but left every chunk sub-decoder without a per-type minimum-length check. The advisory's own description lists "SCTP chunk/parameter decoders (sctp.go)" among items "being confirmed; they should be remediated together with the above" - this report demonstrates that, at v1.7.1 and HEAD, that remediation still does not exist.

Patches

Fixed in v1.7.2 by commit 5080443 ("layers/sctp: bound chunk sub-decoders and parameters"). INIT/INIT-ACK, SACK and SHUTDOWN now check their chunk type's minimum length, SACK rejects gap-ack and duplicate-TSN counts the chunk can't hold, and decodeSCTPParameter rejects TLV lengths below 4 or beyond the buffer. Each case returns a decode error instead of panicking. The same commit fixes a panic on valid input, where a final parameter's padding lies outside the chunk length (RFC 9260 3.2). Regression tests: TestDecodeSCTPChunkRegression and TestDecodeSCTPParameterPadding in layers/decode_oob_test.go.

Upgrade with go get github.com/gopacket/gopacket@v1.7.2.

Workarounds

Before v1.7.2, keep panic recovery on: use gopacket.NewPacket without SkipDecodeRecovery, and DecodingLayerParser with IgnorePanic: false. The crafted packet then fails to decode instead of crashing the process.

Vulnerability Details

All line numbers refer to layers/sctp.go at commit 18c5805028329a6a8944f054d8d3f64ebc0f1373 (master, 2026-09-01; v1.7.1-1-g18c5805).

The shared entry point already present in v1.7.1 validates only that a chunk is present and that its declared length is ≥ 4 and covered by real bytes:

// sctp.go:129
func decodeSCTPChunk(data []byte) (SCTPChunk, error) {
	if len(data) < 4 { ... }
	length := binary.BigEndian.Uint16(data[2:4])
	if length < 4 { ... }
	actual := roundUpToNearest4(int(length))
	ct := SCTPChunkType(data[0])
	if ct == SCTPChunkTypeData && length < 16 { ... }   // only DATA gets a 16-byte minimum
	if len(data) < actual { ... }
	...

The Data-chunk minimum of 16 bytes is never applied to the other chunk types, and none of the sub-decoders re-check before indexing. Four independent panic paths result (each reproduced at HEAD):

Defect 1 - INIT / INIT-ACK chunks (decodeSCTPInit, sctp.go:423): reads data[4:8], data[8:12] (line 431), data[12:14], data[14:16], data[16:20] (line 434), then slices paramData := data[20:sc.ActualLength] (line 436).

• Declared length 8–11, actual 8–12 -> data[8:12] reads past the chunk: panic: runtime error: slice bounds out of range [:12] with capacity 8
• Declared length 15, actual 16 -> data[16:20] past the chunk: panic: runtime error: slice bounds out of range [:20] with capacity 16
• Declared length ≤ 19 -> the data[20:ActualLength] slice is inverted (panic) or…

gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.

gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.

gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.

Summary

gopacket decodes SCTP (IP protocol 132) by walking the chunk chain through per-chunk-type decoder functions (decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, in layers/sctp.go). Each of these reads fixed-size header fields and runs count-driven loops without validating the chunk's declared length against the minimums those reads require. A single crafted SCTP segment causes a runtime panic (out-of-bounds slice read, or inverted slice from unsigned length arithmetic) on any decode path that does not install gopacket's per-packet panic recovery (gopacket.DecodeOptions.SkipDecodeRecovery: true); with the default API the same input degrades to a per-packet decode error.

The defect is present in every released version through v1.7.1 and at current master (18c5805). It is the SCTP component named - but not remediated - in CVE-2026-65819 (GHSA-8mcr-459q-5mx2, "Multiple layer decoders panic …", patched per advisory metadata in v1.7.1). The v1.7.1 hardening commit b772f56 ("layers:various: add protocol decoder length checks (#163)") added generic bounds to the chunk dispatcher and decodeSCTPChunk, but left every chunk sub-decoder without a per-type minimum-length check. The advisory's own description lists "SCTP chunk/parameter decoders (sctp.go)" among items "being confirmed; they should be remediated together with the above" - this report demonstrates that, at v1.7.1 and HEAD, that remediation still does not exist.

Patches

Fixed in v1.7.2 by commit 5080443 ("layers/sctp: bound chunk sub-decoders and parameters"). INIT/INIT-ACK, SACK and SHUTDOWN now check their chunk type's minimum length, SACK rejects gap-ack and duplicate-TSN counts the chunk can't hold, and decodeSCTPParameter rejects TLV lengths below 4 or beyond the buffer. Each case returns a decode error instead of panicking. The same commit fixes a panic on valid input, where a final parameter's padding lies outside the chunk length (RFC 9260 3.2). Regression tests: TestDecodeSCTPChunkRegression and TestDecodeSCTPParameterPadding in layers/decode_oob_test.go.

Upgrade with go get github.com/gopacket/gopacket@v1.7.2.

Workarounds

Before v1.7.2, keep panic recovery on: use gopacket.NewPacket without SkipDecodeRecovery, and DecodingLayerParser with IgnorePanic: false. The crafted packet then fails to decode instead of crashing the process.

Vulnerability Details

All line numbers refer to layers/sctp.go at commit 18c5805028329a6a8944f054d8d3f64ebc0f1373 (master, 2026-09-01; v1.7.1-1-g18c5805).

The shared entry point already present in v1.7.1 validates only that a chunk is present and that its declared length is ≥ 4 and covered by real bytes:

// sctp.go:129
func decodeSCTPChunk(data []byte) (SCTPChunk, error) {
	if len(data) < 4 { ... }
	length := binary.BigEndian.Uint16(data[2:4])
	if length < 4 { ... }
	actual := roundUpToNearest4(int(length))
	ct := SCTPChunkType(data[0])
	if ct == SCTPChunkTypeData && length < 16 { ... }   // only DATA gets a 16-byte minimum
	if len(data) < actual { ... }
	...

The Data-chunk minimum of 16 bytes is never applied to the other chunk types, and none of the sub-decoders re-check before indexing. Four independent panic paths result (each reproduced at HEAD):

Defect 1 - INIT / INIT-ACK chunks (decodeSCTPInit, sctp.go:423): reads data[4:8], data[8:12] (line 431), data[12:14], data[14:16], data[16:20] (line 434), then slices paramData := data[20:sc.ActualLength] (line 436).

• Declared length 8–11, actual 8–12 -> data[8:12] reads past the chunk: panic: runtime error: slice bounds out of range [:12] with capacity 8
• Declared length 15, actual 16 -> data[16:20] past the chunk: panic: runtime error: slice bounds out of range [:20] with capacity 16
• Declared length ≤ 19 -> the data[20:ActualLength] slice is inverted (panic) or…

gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.

gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.