What Is a Teardrop Attack?

A teardrop attack is a denial-of-service technique that sends IP fragments carrying deliberately overlapping offset values, so the target cannot put the original packet back together. Older TCP/IP stacks calculated a negative payload length from those offsets, then copied memory well past the end of a buffer, which froze or crashed the machine outright. One attacker, a handful of malformed packets, one server down. This guide walks through the fragmentation mechanics behind the attack, the variants that followed it, the telemetry that exposes it, and the layered controls that keep fragment-based traffic away from your origin. The strange part is why it keeps coming back.

Key Takeaways

• A teardrop attack forges the 13-bit fragment offset field so two fragments of the same datagram claim overlapping byte ranges.
• Vulnerable stacks compute a negative length during reassembly, then perform an oversized memory copy that panics the kernel.
• The original flaw is tracked as CVE-1999-0015 and hit Windows 3.1x, Windows 95, Windows NT, Linux kernels up to 2.0.32, SunOS, and HP-UX.
• Bonk, Nestea, and Teardrop 2 are the same idea with different offset and length combinations, filed under separate CVE identifiers.
• FragmentSmack, CVE-2018-5391, revived the class two decades later by saturating CPU during reassembly instead of crashing the host.
• Detection relies on fragment share, reassembly timeouts, and incomplete fragment sets rather than on payload signatures.
• Prevention combines patched stacks, reassemble-then-inspect firewall policy, per-source fragment budgets, and edge scrubbing capacity.

How IP Fragmentation Works and Why Attackers Target It

IP fragmentation splits a datagram that exceeds the link maximum transmission unit into smaller pieces, each carrying an offset that tells the receiver where its payload belongs in the original packet. A teardrop attack abuses that offset, because the receiving host has no way to verify the value before it commits memory to the reassembly buffer.

RFC 791 defined the mechanism in 1981. The fragment offset field is 13 bits wide and counts in 8-byte units, so a 4,000-byte datagram crossing a standard 1,500-byte Ethernet link arrives as three fragments with offsets of 0, 185, and 370. The More Fragments flag stays set on every piece except the last one, which is how the receiver knows when the set is complete.

Nothing in that design authenticates the offset. A sender can claim any value it likes, and the receiver has to trust it long enough to allocate space. RFC 1858 documented the security consequences of fragment filtering in 1995, a full two years before working teardrop code started circulating on public mailing lists.

Four properties make the offset field an unusually attractive target:

• The offset arrives ahead of the payload, so the stack commits buffer decisions before it has seen the data.
• Fragments legitimately arrive out of order, so a receiver cannot reject an odd-looking sequence on principle.
• Reassembly runs inside the kernel, where a bad memory copy has no user space safety net to catch it.
• Only the first fragment carries the transport header, so port-based filters see nothing useful in the pieces that follow.

That last property is why the same era produced the ping of death attack, which used an oversized ICMP echo request rather than crooked offsets. Different payload, identical trust assumption underneath.

You might be thinking that fragmentation is a museum piece. On a healthy edge network, fragments account for well under one percent of inbound packets, because path MTU discovery keeps most traffic below the smallest link size along the route. That low baseline is exactly what makes the signal valuable. Anything that pushes fragment share into double digits deserves an investigation, not a shrug.

To see why a forged offset was so destructive, follow the arithmetic the kernel actually performed.

How a Teardrop Attack Works Step by Step

A teardrop attack sends at least two UDP fragments belonging to the same datagram, where the second fragment claims an offset that falls inside the byte range the first fragment already covered, and its length is too short to reach the end of that range. The stack subtracts one value from the other, produces a negative number, and hands that number to a memory copy routine that expects an unsigned integer.

1. The attacker crafts two fragments that share a single IP identification value, so the target treats them as parts of one datagram.
2. The first fragment is sent normally with an offset of zero and the More Fragments flag set.
3. The second fragment carries an offset that points into the middle of the first fragment’s data and a length that stops short of the first fragment’s end.
4. The reassembly routine subtracts the end of the earlier fragment from the start of the later one and gets a negative result.
5. That negative value is interpreted as an enormous positive length, the copy runs off the end of the allocated buffer, and the host panics or hangs.

Written out with real numbers, the failure is almost anticlimactic:

No botnet. No bandwidth. Two datagrams that together weigh less than a single web page request. That gap between effort and impact is the cleanest illustration of the difference between DoS and DDoS approaches, where one exhausts logic and the other exhausts capacity.

The technique was devastating because of who it worked against, and that list is longer than most engineers assume.

Which Systems Teardrop Broke and How Its Variants Evolved

Teardrop is tracked as CVE-1999-0015, published in December 1997, and the affected list spans nearly every mainstream operating system of the period. Windows 3.1x, Windows 95, and Windows NT crashed. Linux kernels before 2.0.31 were vulnerable until Alan Cox and the distribution maintainers corrected the record on Bugtraq. SunOS 4.1.3 and 4.1.4 and multiple HP-UX releases were listed as affected in the national vulnerability database entry.

Within months, several near-identical exploits appeared. Each one changed the offset and length combination just enough to slip past the first round of patches, which is the reason vendors eventually moved to validating the whole fragment set rather than matching individual packet signatures.

Teardrop and its close relatives

The standards bodies eventually removed the ambiguity that made overlaps possible in the first place. For IPv6, the rule is absolute.

“IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT create overlapping fragments.”

Here is what most retrospectives miss. FragmentSmack proved the lesson had not travelled. Disclosed by the National Cyber Security Centre of Finland and the CERT Coordination Center, it crashed nothing at all. It simply fed a target thousands of tiny fragments with random offsets and never sent the final piece, forcing the reassembly queue into expensive repeated work until a CPU core sat at one hundred percent. Linux kernels from version 3.9 onward were affected, along with Windows, Cisco platforms, and Palo Alto firewalls. Same input class, same trusted field, completely different failure mode.

Understanding where teardrop sits next to the flooding techniques your monitoring already tracks makes the operational response much clearer.

Teardrop Attack Compared With Other Denial-of-Service Techniques

Teardrop belongs to the malformed packet category, not the flooding category. It breaks a host by feeding it input the code cannot handle, while flooding techniques break a host by feeding it more valid input than it can process. That distinction decides which control actually stops the traffic.

Malformed packet attacks versus flooding techniques

A SYN flood attack leaves your kernel healthy and your connection table full. A UDP flood attack leaves your kernel healthy and your uplink full. A smurf attack borrows other people’s networks to do the same thing at greater scale. Teardrop leaves your uplink almost empty and your kernel dead, which is precisely why bandwidth-focused monitoring misses it.

Yes, capacity absorbs most modern denial-of-service traffic. But capacity is the wrong answer to a two-packet attack, and buying more of it changes nothing when the failure is a signed integer in a reassembly routine. The correct answer is validation, and validation only works if you can see the fragments in the first place.

How to Detect a Teardrop Attack on Your Network

Detection depends on fragment behavior rather than payload signatures, because a teardrop packet contains no malicious content. The telltale evidence is the shape of the fragment set: overlapping ranges, sets that never complete, and reassembly timers that expire far more often than usual.

Start with packet capture. These display filters isolate the traffic worth examining:

Alongside capture, four metrics belong on a dashboard permanently:

• Fragmented packet share as a percentage of inbound packets, with an alert threshold set just above your measured baseline.
• Reassembly timeout counters from the host, available on Linux through the IP statistics in the network stack counters.
• Incomplete fragment sets held in the queue, which climb steadily under a FragmentSmack style attack and stay flat otherwise.
• Unexplained kernel resets, driver restarts, or blue screens on the same subnet within a short window.

Record a fragment share baseline during a normal week before you set any threshold. A tunnel endpoint, a VPN concentrator, or a DNS resolver handling large responses can legitimately sit at five percent, and a generic alert rule will page you every night for nothing.

Detection tells you it is happening. The controls below decide whether it matters.

How to Prevent Teardrop Attacks and Fragment-Based Floods

Prevention works in layers, because no single control covers every case. A patched kernel stops the crash. A firewall that reassembles before it inspects stops the evasion. Edge capacity and fragment budgets stop the volumetric variants that no host-level fix can absorb.

1. Patch every operating system, router, load balancer, and firewall in the path. Modern kernels reject overlapping offsets outright, and the FragmentSmack fixes are shipped across all supported vendor lines.
2. Configure firewalls and intrusion prevention systems to reassemble the full datagram before applying policy, so a rule that blocks a port cannot be bypassed by hiding the header in a later fragment.
3. Drop overlapping fragment sets at the perimeter. Legitimate traffic almost never produces them, so a blanket drop rule carries very little false positive risk.
4. Cap the memory and the number of fragments a single source may hold in the reassembly queue, which neutralizes attacks that rely on incomplete sets accumulating.
5. Block fragments entirely on services that never need them, such as an HTTPS listener behind a proxy that terminates connections at the edge.
6. Push filtering upstream to a distributed network so malformed packets are dropped near their source rather than at your uplink. A dedicated DDoS solution can provide this protection before malicious traffic reaches the origin.

On Linux hosts and appliances, the reassembly queue is directly tunable, and these were the workarounds vendors recommended during the FragmentSmack response:

Host tuning has a ceiling. Once fragment volume exceeds what your uplink can carry, the packets have to be filtered before they reach you, which is the job a layer 4 shield performs at the network edge. Pair that filtering with rate limiting on the sources generating abnormal fragment volume, and the two controls together handle both the crafted single packet case and the sustained flood case.

All of which raises the obvious question. If every current stack is patched, why does any of this still deserve dashboard space?

Why Fragment Attacks Still Show Up in Modern Traffic

Because the patched population is smaller than the internet, and because the technique has been repurposed. Classic teardrop no longer crashes a maintained server, but three conditions keep the family alive: unpatched embedded devices, middleboxes with reassembly logic that disagrees with the host behind them, and attackers who use fragments as a delivery mechanism rather than as the payload.

The scale context matters here. Cloudflare mitigated 23.2 million network-layer attacks in the first half of the year, yet reported that the median attack stayed small, with the overwhelming majority of network-layer events under 500 Mbps and more than ninety percent finishing inside ten minutes. Small, short, and precisely targeted is the normal case, not the exception, and that profile fits a malformed packet technique far better than it fits a terabit flood.

The second reason is operational rather than technical. Fragmentation is a reliable way to hide traffic from inspection, so it turns up as a component inside larger campaigns. A volumetric DDoS attack that pads packet sizes through fragmentation can inflate a hundred-byte packet into a ten-kilobyte reassembled datagram, which distorts any quota measured on reassembled traffic. A botnet DDoS attack with fragmentation enabled forces every device in the path to spend CPU on reassembly before a single policy decision gets made.

Which is the point worth carrying forward. Teardrop itself is a solved problem on a maintained fleet. The assumption underneath it, that an offset supplied by a stranger can be trusted, keeps producing new vulnerabilities in every generation of network code that has to reassemble something.

Final Thought on Teardrop Attacks

A teardrop attack is not a bandwidth problem, and treating it as one leads to the wrong investment. It is a validation problem, and it stays solved only for as long as every device in the path keeps validating fragment offsets correctly and keeps getting patched when that logic changes.

The practical version of that principle is short. Know your normal fragment share, alert on deviation from it, reassemble before you inspect, cap what any single source can hold in the queue, and keep the kernels and appliances current. Those five habits cost very little and cover the entire fragmentation family, including the variant that has not been named yet.

Common Questions About Teardrop Attacks