What is the ping of death?

02How the original attack worked

IP fragmentation splits a large packet into pieces that each carry an offset saying where they belong in the reassembled whole. The receiver buffers the fragments and stitches them back together using those offsets.

The attack set the offset and length of the final fragment so that offset plus payload exceeded 65,535 bytes. A stack that trusted the fragments and copied them into a fixed buffer wrote past the end of it. The result was memory corruption and, typically, an immediate crash, freeze or reboot — denial of service with a single crafted message.

The defence is simple once known: before reassembling, check that the highest fragment offset plus its length cannot exceed the maximum packet size, and drop the set if it does. Every current stack does this, which is why you can no longer ping a modern host to death.

03How to spot ping-of-death packets in a capture

Look for a fragment whose offset plus its length would place data beyond byte 65,535 of the reassembled packet. No legitimate sender produces one, so a single match is a clear signature. A patched host discards it harmlessly, but seeing it tells you someone is probing for legacy stacks — worth knowing if old printers, embedded controllers or unmaintained appliances share the network.

The two filters below were validated with tcpdump 4.99.3 against a crafted capture on Debian 12: the first matched every fragment, the second only the one whose offset and length overflowed the limit. Overlapping fragments in the Teardrop style cannot be caught by a single-packet filter, because spotting them means comparing fragments that share an ID; that takes a reassembly-aware intrusion-detection system.

# any fragment (More-Fragments set or non-zero offset)
tcpdump -ni eth0 'ip[6:2] & 0x3fff != 0'

# fragments whose offset+length would exceed 65535 bytes
# (reassembled size overflow — the ping-of-death signature)
tcpdump -ni eth0 '((ip[6:2] & 0x1fff) * 8) + ip[2:2]
                  - ((ip[0] & 0x0f) * 4) > 65535'

04Modern cousins: the idea did not die

The specific 1996 bug is gone, but abusing fragment reassembly and malformed-packet parsing remains a live category. The table lists the notable descendants, each traceable to a primary source.

05Teardrop and fragmentation attacks

Teardrop, disclosed alongside Land in CERT CA-1997-28, is the ping of death's closest sibling. Instead of an oversized total it sent overlapping fragment offsets — pieces that claimed to occupy the same bytes. Reassembly code that computed a copy length by subtracting offsets could underflow and crash. There was no clean workaround at the time; the fix was in the kernel.

FragmentSmack (CVE-2018-5391) modernised the theme into a resource attack rather than a crash: a low rate of specially modified fragments forced the Linux reassembly code into its most expensive path, saturating the CPU. The mitigation that does not need a patch is to cap the reassembly memory — `net.ipv4.ipfrag_high_thresh` and `net.ipv4.ipfrag_low_thresh`, plus their IPv6 counterparts — though Red Hat presented this only as a stop-gap that reduces CPU load during an attack, with the fixed kernel as the real remedy.

The practical lesson is that fragmentation is a persistent soft spot. Where you control it, dropping or rate-limiting non-initial fragments at the edge removes a whole class of these attacks; this is also one of the levers used against carpet-bombing floods.

• Keep operating systems and network-device firmware current — these are code bugs, and the fix is the patch
• Where supported, enable reassembly limits so a fragment flood cannot exhaust memory or CPU
• Drop obviously malformed fragment sets at a filtering layer with the capacity to inspect them
• Disable IPv6 only if you genuinely do not use it; several modern cousins are IPv6-specific, but disabling a protocol you need causes its own outages

06Can a WAF or reverse proxy help?

Be honest about this one: the classic ping of death and its reassembly cousins are bugs in the target's own network stack, and the real fix is patching that stack. A reverse proxy or WAF operating at the HTTP layer never sees raw IP fragments destined for your origin, so it cannot filter them for you. Virtual patching at a WAF does not change that either, because it recognises an attack inside an HTTP request, not in the IP packets that carry it.

What upstream network filtering can do is drop malformed and abusive fragment traffic before it reaches a protected address at all — useful for the fragment-flood variants like FragmentSmack. That is a property of routed Layer 3/4 filtering — the model behind GRE transit, which is coming soon — not of an application proxy. For the remote-code-execution cousins such as the Windows IPv6 flaws, no edge device substitutes for installing the vendor update. If you want to track those specifically, they live in the vulnerabilities centre.