CVE-2026-54345

gopacket provides packet processing capabilities for Go. In version 1.6.0 and earlier, the Diameter AVP decoder computes an AVP data length by subtracting a fixed header size from an attacker-controlled AVP Length field, so a vendor-flagged AVP whose Length is smaller than the 12-byte header underflows the unsigned 32-bit value and drives an unbounded allocation of roughly 4 GiB, and two such messages in succession OOM-kill a collector, causing an unauthenticated remote denial of service. This issue is fixed in version 1.6.1.

gopacket provides packet processing capabilities for Go. In version 1.6.0 and earlier, the Diameter AVP decoder computes an AVP data length by subtracting a fixed header size from an attacker-controlled AVP Length field, so a vendor-flagged AVP whose Length is smaller than the 12-byte header underflows the unsigned 32-bit value and drives an unbounded allocation of roughly 4 GiB, and two such messages in succession OOM-kill a collector, causing an unauthenticated remote denial of service. This issue is fixed in version 1.6.1.

Summary

The Diameter AVP decoder in github.com/gopacket/gopacket computes dataLength := avp.Length - uint32(headerSize) without first ensuring avp.Length >= headerSize. When the Vendor flag is set, headerSize is 12, but the only length guard upstream rejects avp.Length < 8. An AVP with the Vendor flag set and a 24-bit Length field of 8, 9, 10, or 11 therefore underflows the uint32 subtraction to ~4,294,967,292, which is passed straight to make([]byte, dataLength). A single 32-byte Diameter message forces a ~4 GiB allocation; a short burst of such messages exhausts memory and OOM-kills memory-constrained collectors. This is an unauthenticated remote denial of service (CWE-191 integer underflow -> CWE-770 unbounded allocation).

Root cause (file:line @ v1.6.0)

layers/diameter_avp_decoders.go, decodeDiameterAVP:

avp.Length = uint32(data[5])<<16 | uint32(data[6])<<8 | uint32(data[7]) // 24-bit wire value

if avp.Length < 8 {                       // only rejects < 8
    return DiameterAVP{}, 0, fmt.Errorf("invalid AVP length: %d", avp.Length)
}

headerSize := 8
dataOffset := 8
if avp.Flags.Vendor {                     // Vendor flag = wire bit data[4] & 0x80
    if len(data) < 12 { ... }
    avp.VendorID = binary.BigEndian.Uint32(data[8:12])
    headerSize = 12                       // header is now 12, but only >= 8 was checked
    dataOffset = 12
}

paddedLength := avp.Length                // equals avp.Length; for avp.Length <= 12
if avp.Length%4 != 0 { paddedLength = avp.Length + (4 - avp.Length%4) }
if uint32(len(data)) < paddedLength {     // only requires ~12 bytes present
    return DiameterAVP{}, 0, fmt.Errorf("AVP data truncated: ...")
}

dataLength := avp.Length - uint32(headerSize)  // 8 - 12 = uint32 underflow = 4294967292
avp.Data = make([]byte, dataLength)            // make([]byte, ~4.29e9) ~= 4 GiB
copy(avp.Data, data[dataOffset:dataOffset+int(dataLength)])  // out-of-bounds slice -> panic

For avp.Length in {8, 9, 10, 11} with the Vendor flag set: the avp.Length < 8 guard passes, paddedLength == avp.Length so only avp.Length bytes must be present, and dataLength = avp.Length - 12 underflows the uint32. The allocation size is determined entirely by the attacker-supplied 3-byte Length field plus a single flag bit. The make executes before the copy, so the multi-gigabyte allocation is requested regardless of whether the copy later panics.

Reachability (remote attacker -> sink)

LayerTypeDiameter is a registered decoder (layertypes.go:159, RegisterLayerType(154, ... decodeDiameter)):

decodeDiameter -> (*Diameter).DecodeFromBytes (diameter.go:118) -> parses the 20-byte header -> avpData := data[20:d.MessageLength] -> AVP loop decodeDiameterAVP(avpData) (diameter.go:158) -> sink at diameter_avp_decoders.go:57.

Diameter (RFC 6733) is a TCP/SCTP base protocol used for AAA and telecom/5G signaling. Any service that parses Diameter with gopacket (packet collectors, signaling monitors, IDS/analysis tooling) processes attacker-sent or attacker-forwarded Diameter messages with no authentication involved, so any host able to deliver such a message to the parser reaches the sink. The same path is reached via gopacket.NewPacket(data, LayerTypeDiameter, ...). The Diameter layer is specific to this gopacket fork (the original google/gopacket has no Diameter layer), so there is no upstream sibling fix.

Impact

Unauthenticated remote denial of service via memory exhaustion. Each malicious 32-byte Diameter message requests a ~4 GiB allocation (amplification ~1.34e8x over the input). There is no memory corruption and no code execution -- the impact is resource exhaustion / process termination. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).

Note on consumer behavior (measured end-to-end against a deployed collector, see PoC):

• A collector using the recovering gopacket.NewPacket(..., gopacket.Default) API…

gopacket provides packet processing capabilities for Go. In version 1.6.0 and earlier, the Diameter AVP decoder computes an AVP data length by subtracting a fixed header size from an attacker-controlled AVP Length field, so a vendor-flagged AVP whose Length is smaller than the 12-byte header underflows the unsigned 32-bit value and drives an unbounded allocation of roughly 4 GiB, and two such messages in succession OOM-kill a collector, causing an unauthenticated remote denial of service. This issue is fixed in version 1.6.1.

gopacket provides packet processing capabilities for Go. In version 1.6.0 and earlier, the Diameter AVP decoder computes an AVP data length by subtracting a fixed header size from an attacker-controlled AVP Length field, so a vendor-flagged AVP whose Length is smaller than the 12-byte header underflows the unsigned 32-bit value and drives an unbounded allocation of roughly 4 GiB, and two such messages in succession OOM-kill a collector, causing an unauthenticated remote denial of service. This issue is fixed in version 1.6.1.

Summary

The Diameter AVP decoder in github.com/gopacket/gopacket computes dataLength := avp.Length - uint32(headerSize) without first ensuring avp.Length >= headerSize. When the Vendor flag is set, headerSize is 12, but the only length guard upstream rejects avp.Length < 8. An AVP with the Vendor flag set and a 24-bit Length field of 8, 9, 10, or 11 therefore underflows the uint32 subtraction to ~4,294,967,292, which is passed straight to make([]byte, dataLength). A single 32-byte Diameter message forces a ~4 GiB allocation; a short burst of such messages exhausts memory and OOM-kills memory-constrained collectors. This is an unauthenticated remote denial of service (CWE-191 integer underflow -> CWE-770 unbounded allocation).

Root cause (file:line @ v1.6.0)

layers/diameter_avp_decoders.go, decodeDiameterAVP:

avp.Length = uint32(data[5])<<16 | uint32(data[6])<<8 | uint32(data[7]) // 24-bit wire value

if avp.Length < 8 {                       // only rejects < 8
    return DiameterAVP{}, 0, fmt.Errorf("invalid AVP length: %d", avp.Length)
}

headerSize := 8
dataOffset := 8
if avp.Flags.Vendor {                     // Vendor flag = wire bit data[4] & 0x80
    if len(data) < 12 { ... }
    avp.VendorID = binary.BigEndian.Uint32(data[8:12])
    headerSize = 12                       // header is now 12, but only >= 8 was checked
    dataOffset = 12
}

paddedLength := avp.Length                // equals avp.Length; for avp.Length <= 12
if avp.Length%4 != 0 { paddedLength = avp.Length + (4 - avp.Length%4) }
if uint32(len(data)) < paddedLength {     // only requires ~12 bytes present
    return DiameterAVP{}, 0, fmt.Errorf("AVP data truncated: ...")
}

dataLength := avp.Length - uint32(headerSize)  // 8 - 12 = uint32 underflow = 4294967292
avp.Data = make([]byte, dataLength)            // make([]byte, ~4.29e9) ~= 4 GiB
copy(avp.Data, data[dataOffset:dataOffset+int(dataLength)])  // out-of-bounds slice -> panic

For avp.Length in {8, 9, 10, 11} with the Vendor flag set: the avp.Length < 8 guard passes, paddedLength == avp.Length so only avp.Length bytes must be present, and dataLength = avp.Length - 12 underflows the uint32. The allocation size is determined entirely by the attacker-supplied 3-byte Length field plus a single flag bit. The make executes before the copy, so the multi-gigabyte allocation is requested regardless of whether the copy later panics.

Reachability (remote attacker -> sink)

LayerTypeDiameter is a registered decoder (layertypes.go:159, RegisterLayerType(154, ... decodeDiameter)):

decodeDiameter -> (*Diameter).DecodeFromBytes (diameter.go:118) -> parses the 20-byte header -> avpData := data[20:d.MessageLength] -> AVP loop decodeDiameterAVP(avpData) (diameter.go:158) -> sink at diameter_avp_decoders.go:57.

Diameter (RFC 6733) is a TCP/SCTP base protocol used for AAA and telecom/5G signaling. Any service that parses Diameter with gopacket (packet collectors, signaling monitors, IDS/analysis tooling) processes attacker-sent or attacker-forwarded Diameter messages with no authentication involved, so any host able to deliver such a message to the parser reaches the sink. The same path is reached via gopacket.NewPacket(data, LayerTypeDiameter, ...). The Diameter layer is specific to this gopacket fork (the original google/gopacket has no Diameter layer), so there is no upstream sibling fix.

Impact

Unauthenticated remote denial of service via memory exhaustion. Each malicious 32-byte Diameter message requests a ~4 GiB allocation (amplification ~1.34e8x over the input). There is no memory corruption and no code execution -- the impact is resource exhaustion / process termination. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).

Note on consumer behavior (measured end-to-end against a deployed collector, see PoC):

• A collector using the recovering gopacket.NewPacket(..., gopacket.Default) API…