A Teardrop attack is a classic IP fragmentation exploit that sends packet fragments with deliberately overlapping offset values, causing vulnerable TCP/IP stacks to fail or crash when they attempt to reassemble the fragments into a coherent packet. It is a specific, historical example of the broader IP fragmentation attack category, dating to the mid-1990s, and is largely mitigated in modern operating systems.
TL;DR: Teardrop crafts a sequence of IP fragments whose offset and length fields overlap in a way that is inconsistent with a valid original packet — for example, a second fragment claiming to start before the first one ends. Older reassembly code computed buffer copy lengths using simple offset subtraction and did not validate that fragments were non-overlapping, producing negative or invalid length values that corrupted memory or triggered a crash. Windows 95, Windows NT, and early Linux kernels were patched against Teardrop in 1997. Modern kernels validate fragment overlap and reject inconsistent fragment sets, though the same overlapping-fragment technique remains a documented evasion method against poorly configured intrusion detection systems.
Last updated: 2026-08-27
How the Attack Works
IP fragmentation splits a large packet into smaller pieces for transmission across networks with a smaller maximum transmission unit (MTU); each fragment carries an offset field indicating where its payload belongs in the reassembled packet. A valid fragment sequence has offsets and lengths that fit together without overlapping. Teardrop deliberately violates this.
Valid fragmentation:Fragment 1: offset=0, length=1400 [covers bytes 0-1399]Fragment 2: offset=1400, length=1400 [covers bytes 1400-2799] → reassembles cleanly, no overlap
Teardrop overlapping fragments:Fragment 1: offset=0, length=1400 [covers bytes 0-1399]Fragment 2: offset=1000, length=1400 [claims to cover bytes 1000-2399] │ ▼Reassembly code computes: copy_length = fragment2.end - fragment2.offsetOn vulnerable stacks, overlapping offset math produces a negativeor invalid length value, which is then used in a memory copy │ ▼Buffer under-write/overflow → kernel crash or system freezeThe defect was in how early reassembly routines calculated how many bytes of a new fragment to copy into the reassembly buffer relative to fragments already received. Because the code assumed fragments would never overlap, it did not clamp or validate the computed length before using it in a memory copy operation, and a specially crafted negative-length scenario corrupted kernel memory.
Historical Context
Teardrop was identified and publicized in late 1997, shortly after Ping of Death had already drawn attention to fragmentation and reassembly bugs in TCP/IP stacks. It affected Windows 95, Windows NT 3.51 and 4.0, and early Linux kernel versions (prior to 2.0.32 and 2.1.63). A related variant known as “Teardrop2” (or “NewTear”/“Bonk”/“Boink” in some naming from the era) targeted UDP-based services with similar overlapping-fragment logic. Microsoft and Linux kernel maintainers released patches in late 1997 and early 1998 that added overlap validation to fragment reassembly code, and CERT/CC documented the vulnerability and mitigation guidance in advisories from that period.
Teardrop vs. General IP Fragmentation Attacks
Teardrop is one specific historical technique within the broader IP fragmentation attack category, which covers any attack that manipulates fragment size, offset, count, or ordering to evade defenses or exhaust resources.
| Aspect | Teardrop (specific attack) | IP Fragmentation Attack (general category) |
|---|---|---|
| Technique | Overlapping fragment offsets | Any fragment manipulation: overlap, tiny fragments, missing fragments, excessive fragment count |
| Primary goal | Crash the target via a reassembly bug | Crash, evade inspection, or exhaust reassembly resources |
| Era | Specific 1996-1997 exploit | Ongoing category, still relevant for evasion and resource exhaustion |
| Modern relevance | Historical; patched in mainstream OSes | Active; used for IDS/firewall evasion and reassembly resource exhaustion |
| Root cause class | Software defect in overlap handling | Can be a software defect or a design limitation of stateless inspection |
Any discussion of fragmentation-based denial of service should treat Teardrop as a named historical instance rather than a synonym for the category — modern fragmentation attacks (fragment floods, tiny-fragment evasion, out-of-order fragment attacks) do not rely on the same offset-overlap software bug that made Teardrop possible.
Why Modern Systems Are Largely Immune
Modern kernels validate fragment offset and length consistency during reassembly and explicitly detect and discard overlapping fragments rather than trusting the incoming offset values, per hardening that followed RFC 791 and IP reassembly guidance in RFC 815 and later reassembly-security literature (RFC 1858 and RFC 3128 address related fragment evasion concerns). This validation has been standard in Windows, Linux, BSD-derived systems, and network security appliances for more than two decades.
Residual risk remains in:
- Embedded and IoT devices running minimal, unpatched, or custom TCP/IP stacks
- Legacy industrial control systems with long hardware lifecycles and infrequent patching
- Security appliances with weak fragment reassembly that can still be evaded (not crashed) using overlapping or out-of-order fragments to hide malicious payloads from signature-based inspection
Detection and Mitigation
- Kernel-level fragment validation — reject or normalize fragments with inconsistent or overlapping offsets before reassembly, standard in modern OS network stacks
- IP fragment reassembly limits — bound the number of fragments and total reassembly buffer size accepted per packet at the firewall or host
- Firewall rules dropping malformed fragments — filter fragment sequences with overlapping offsets or invalid length combinations at the network perimeter
- Normalize before inspect — security appliances performing deep packet inspection should reassemble and normalize fragments consistently with the destination host’s behavior to avoid evasion
- Patch and asset management — track legacy and embedded devices still running pre-1998-era or custom network stacks that may lack overlap validation
How to Implement on Azion
Azion’s DDoS Protection inspects and filters malformed and overlapping IP fragments at the network edge before they reach origin infrastructure. Network Shield can help enforce fragment reassembly limits and drop packets with inconsistent offset or length values at Layers 3 and 4. Firewall rules can be configured to restrict fragmented traffic patterns for origins that do not expect fragmented input, reducing exposure for legacy backend systems.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is DDoS Protection and Mitigation?
- What Is an IP Fragmentation Attack?
- Azion DDoS Protection
Frequently Asked Questions
What is a Teardrop attack? A Teardrop attack sends IP fragments with deliberately overlapping offset values, which caused older TCP/IP stacks to compute invalid buffer copy lengths during reassembly and crash. It is a specific historical exploit from 1997 rather than a general term for fragmentation attacks.
Is Teardrop still a threat today? No, not as a crash exploit — mainstream operating systems have validated fragment overlap during reassembly for more than two decades. Overlapping-fragment techniques derived from the same idea can still be used for evasion against poorly configured inspection systems, but they no longer crash patched hosts.
How is Teardrop different from a general IP fragmentation attack? IP fragmentation attack is the broad category covering any manipulation of fragment size, offset, count, or order. Teardrop is one specific, named 1997-era technique within that category, defined by its use of overlapping offsets to trigger a reassembly software bug.
Which operating systems were vulnerable to Teardrop? Windows 95, Windows NT 3.51 and 4.0, and Linux kernels prior to versions 2.0.32 and 2.1.63 were vulnerable. Patches were released by Microsoft and Linux kernel maintainers in late 1997 and early 1998.
How does fragment overlap cause a crash? Vulnerable reassembly code computed how many bytes of a new fragment to copy relative to already-received data using simple offset subtraction, without checking for overlap. A crafted overlapping fragment produced a negative or invalid length value used in a memory copy, corrupting kernel memory.
Can Teardrop be used against modern Linux or Windows systems? No. Current kernels detect and discard fragments with inconsistent or overlapping offsets during reassembly rather than trusting the offset values as-is, which eliminates the specific software defect Teardrop exploited.
What is “Teardrop2” or “Bonk/Boink”? These were closely related variants from the same era that applied similar overlapping-fragment or malformed-offset techniques to UDP-based services rather than the original Teardrop’s approach, exploiting comparable reassembly weaknesses in the affected stacks.
Does Teardrop require a high volume of traffic? No. Like other 1990s single-packet crash exploits, Teardrop could disable a vulnerable target with a very small number of crafted fragments, since it exploited a software defect rather than relying on resource exhaustion through volume.
How do modern firewalls handle overlapping fragments? Modern firewalls and intrusion prevention systems detect overlapping fragments and either drop the entire fragment set or reassemble them using rules consistent with the protected host’s behavior, preventing both the historical crash and modern inspection-evasion uses of fragment overlap.
Are IoT and embedded devices still at risk from Teardrop-style bugs? Some embedded devices with minimal or custom-written TCP/IP stacks may not implement full overlap validation, making them a residual risk category, though this is now uncommon compared to the wide exposure seen in 1997.
What RFCs are relevant to understanding Teardrop and its mitigation? RFC 791 defines the IP fragmentation mechanism and offset field that Teardrop abuses; RFC 815 covers reassembly algorithms; RFC 1858 and RFC 3128 document related fragment-based evasion concerns for security devices.
Sources
- CERT/CC. Advisories documenting the Teardrop and related fragmentation vulnerabilities, 1997.
- IETF. “Internet Protocol.” RFC 791. 1981.
- IETF. “IP Datagram Reassembly Algorithms.” RFC 815. 1982.
- IETF. “Security Considerations for IP Fragment Filtering.” RFC 1858. 1995.
- IETF. “Protection Against a Variant of the Tiny Fragment Attack.” RFC 3128. 2001.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.