A teardrop attack breaks a host by handing its IP reassembly code fragments that contradict each other, rather than by sending it more traffic than it can carry. It is the classic named fragmentation vector, and one of the cases a thorough DDoS test exercises for correctness rather than capacity. It belongs to the malformed-packet family, where the damage comes not from volume but from a single deformed packet that breaks the code parsing it, the same lineage as the ping of death. What is specific to teardrop is the deformity it uses: overlapping IP fragment offsets.
Overlapping fragments
When an IP packet is too large for a link, it travels as fragments, each carrying an offset that says where its payload belongs in the reassembled whole. The receiver trusts those offsets to stitch the pieces back together, so it belongs to the broader IP fragmentation surface.
A teardrop sends fragments whose offsets overlap: the second fragment claims to begin inside the range the first already filled, and the byte ranges do not line up. A reassembly routine that computes how much to copy by subtracting one offset from another arrives at a negative or nonsensical length. Fed into a memory copy that expects an unsigned value, that length becomes enormous, and the kernel writes far past the buffer or panics on the spot.
This is the mirror image of its sibling. The ping of death overflows by making the reassembled total too large; teardrop corrupts by making the fragments overlap so the arithmetic underflows. Same handling code, opposite trigger, which is why the two are drawn as one family but tested as separate cases.
Why it still matters
The original teardrop hit hard because the bug was everywhere. In 1997 it crashed Windows 3.1, 95, and NT, and Linux kernels before 2.0.32, since bounds-checking the fragment arithmetic was not yet routine. Vendors fixed it by validating that offsets and lengths stay consistent before the copy, and modern kernels have rejected overlapping fragments for decades.
The class outlives the specific bug. Fragment reassembly is fiddly, unsigned arithmetic is unforgiving, and every new stack that touches the path (a NIC offload feature, an embedded TCP/IP library, a middlebox that reassembles on a host's behalf) is a fresh chance to reintroduce the mistake. IoT and appliance firmware, which lags years behind on updates, is where overlapping-fragment bugs still surface. The attack costs almost no bandwidth, so there is no volumetric signature to catch; the whole event can be a handful of packets.
What a DDoS test measures
The test is a correctness check, and the input has to be built deliberately. A teardrop case is not simply a malformed packet: it is a set of fragments whose offsets and lengths deliberately contradict each other, so that the second fragment claims to begin inside the range the first has already filled. Reassembly code that subtracts one offset from another to size a copy is where the original bug lived, and a case that does not create that overlap is not testing anything.
So a useful exercise varies the arithmetic rather than the volume. Overlapping ranges, a fragment that ends before it begins, duplicate offsets, fragments arriving out of order, and a final fragment that never comes at all are each a different branch of the same code path, and a stack can handle one correctly while mishandling another.
Where reassembly happens matters as much as whether it is correct. The host is only one candidate: a firewall, a load balancer, or any middlebox that reassembles on the host's behalf runs its own implementation, and a test that reaches only the server has not exercised the appliance in front of it. Embedded and IoT firmware is where the oldest code survives, which is why this vector keeps reappearing in devices built long after the original fix.
There is also a resource question that has nothing to do with crashing. A stack holding incomplete fragment sets is holding memory while it waits for pieces that may never arrive, so a stream of deliberately incomplete sets can exhaust the reassembly buffer even where the arithmetic is sound. That failure is quiet, it looks like degradation rather than a crash, and it is worth measuring separately.
The shared history with the ping of death is that both were patched in the same era and both return through new implementations rather than old ones. Fragmentation handling is one of several places where correctness rather than capacity decides whether a service stays up, and Understanding DDoS Attack Vectors sets out the rest.