All DDoS Definitions
DDoS Testing Definition

Ping of Death

The ping of death was first documented in 1996, when a single oversized ICMP packet could reliably crash Windows, Linux and Mac systems outright. The original bug was patched within a year. It keeps returning because every new IP stack has to reimplement fragment reassembly, and each reimplementation is a fresh chance to get it wrong, which is why a DDoS test still includes it. Unlike a flood, it does not rely on volume: a single deliberately oversized packet reaches a parser that trusted its own arithmetic, and the host crashes, hangs, or reboots. It is a denial-of-service primitive of the cheapest possible kind, one packet against one bug.

Ping of Death: fragments that reassemble past the legal limit Attacker oversized ICMP echo split into fragments fragments IP reassembly buffer 65,535-byte IP max legal reassembled bytes overflow reassembled fragments run past the maximum crash Target buffer overflows on reassembly: crash / reboot A test confirms fragment reassembly and packet-validation paths reject malformed, oversized input instead of crashing. BlackNeuron
Diagram of a ping of death: an ICMP echo request delivered as fragments reassembles past the 65,535-byte maximum IP packet size, overflowing the reassembly buffer and crashing a vulnerable host.

How the ping of death works

The whole attack turns on one number. The IPv4 header stores total packet length in a 16-bit field, which caps a legal IP packet at 65,535 bytes. No single frame is that large, so oversized data travels as fragments that the receiver stitches back together, and a correct stack sizes its reassembly buffer for that 65,535-byte ceiling and no more.

The ping of death cheats the reassembly. The attacker sends fragments whose fragment-offset plus payload length adds up past 65,535 bytes. A host that copies each fragment into the buffer using the attacker-supplied offset, without first checking that offset plus length stays within bounds, writes past the end of the buffer. That overflow lands in adjacent kernel memory, and the result is a panic, a hang, or a reboot rather than a rejected packet.

The classic carrier is an ICMP echo request, which is why the attack is named after ping and why the original proof of concept was as blunt as ping -l 65510 from an early Windows box. The carrier is incidental, though. Any IP protocol whose fragments the target reassembles can deliver the same oversized payload; ICMP was simply the easiest tool on hand. What makes it a fragmentation attack at heart is that the danger lives entirely in how the reassembly path handles offsets and lengths, not in the ping itself.

Why it still matters

In 1996 and 1997 the ping of death was close to universal. It downed Windows 3.1, 95, and NT, several Unix variants, Macs, and a long tail of embedded devices such as network printers and routers, because bounds-checking the reassembly buffer simply was not standard practice. Vendors patched it by validating offset and length before the copy, and modern kernels have rejected oversized reassembly for decades, so the original attack is largely historical.

The class it belongs to is not. Malformed and oversized fragments keep breaking parsers whenever new code touches the reassembly path. In October 2020 CVE-2020-16898, nicknamed Bad Neighbor, showed a ping-of-death-shaped flaw in Windows: a crafted ICMPv6 Router Advertisement could corrupt memory and crash or potentially execute code, a fresh instance of the same lesson in the IPv6 stack. That is the point worth carrying: the specific 1997 bug is dead, but "a parser trusted a length field an attacker controlled" is an evergreen failure mode.

This is also what separates the ping of death from its malformed-packet siblings. A teardrop attack uses overlapping fragment offsets rather than an oversized total, and a land attack sets the source equal to the destination to confuse the state machine. Each one breaks a different assumption in the same handling code, which is why they are drawn as one family but tested as distinct cases.

Ping of death Normal fragments Oversized fragment set IP reassembly reassembly buffer overflow Crash / reboot One malformed packet past the 65,535-byte ceiling, not a flood BlackNeuron
Ping of death in motion: well-formed packets parse cleanly until one oversized fragment set reassembles past the 65,535-byte limit and the reassembly path fails

What a DDoS test measures

A test for this class is not a bandwidth test, it is a correctness test. The question is whether the fragment-handling and packet-validation paths reject malformed and oversized input cleanly instead of crashing on it, and the honest way to check is to send the malformed input and watch what the host does.

The value is highest right after change. A kernel upgrade, a new NIC offload feature, a firewall or load-balancer firmware bump, or a middlebox that reassembles fragments on the host's behalf can all reintroduce a reassembly bug that was fixed years ago. A test that replays oversized and overlapping fragments after each such change confirms the stack still drops them rather than trusting that a 1997 fix is still holding. Where the ping of death sits among the other malformed and volumetric vectors is laid out in Understanding DDoS Attack Vectors.