UBUNTU-CVE-2026-119299: Medium severity ubuntu/golang-github-gopacket-gopacket vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
gopacketto a version that resolves this vulnerability.Fixed in 1.7.2
Event History
Frequently Asked Questions
Which applications are realistically exposed to a denial of service?
Applications that decode attacker-controlled SCTP traffic with gopacket are exposed if they use DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled. A crafted SCTP segment can trigger a panic and terminate those applications.
Does an attacker need authentication or user interaction to trigger the issue?
No. The vulnerability is network-reachable and requires an attacker to supply a crafted SCTP segment; no privileges or user interaction are required.
Are applications using gopacket's default recovery behavior protected from process termination?
Yes, the default recovery-enabled APIs convert the malformed packet condition into a per-packet decode error rather than allowing the panic to terminate the application. The issue remains relevant where recovery is explicitly skipped or ignored.
What can be done before upgrading?
Avoid SkipDecodeRecovery, direct registered decoders, and DecodingLayerParser with IgnorePanic enabled when processing untrusted SCTP traffic. Use recovery-enabled decoding so malformed packets are handled as decode errors, then upgrade to version 1.7.2.