CVE-2026-54345

The vulnerability is an unsigned integer underflow in gopacket's Diameter protocol decoder. When parsing vendor-flagged AVPs, the code subtracts a fixed header size (8 bytes) from the AVP Length field, which comes directly from the network. For vendor AVPs with Length values less than 12, this subtraction wraps around to approximately 4 GiB, causing the decoder to attempt a massive allocation that OOM-kills the process. What makes this notable is not the underflow itself—integer handling bugs are common—but the position in the parsing flow where it occurs: after reading the length from the wire but before any bounds validation. The code performs arithmetic on attacker-controlled data before confirming that data is even valid. This is a structural pattern worth examining across your decoder implementations. For immediate mitigation, verify your gopacket version includes a bounds check that rejects AVPs where Length < 12 for vendor-flagged entries before any arithmetic. If you're maintaining custom decoders built on gopacket, audit them for the same pattern: any computation of `length - fixed_header` performed on a uint32 or uint16 extracted from wire format before validating the result is positive. The broader concern raised by this CVE is whether other protocol decoders in gopacket (RADIUS, GTP, H225, or similar variable-length AVP-style structures) share this validation ordering. Even with a patch for Diameter, the underlying pattern—unsigned types used for length fields, arithmetic before validation—may persist elsewhere. Treat this as a signal to audit your decoder surface, not just patch this one AVP path.

Reviewed through automated stages and approved by a human before publication.