CVE-2019-11478 · Linux kernel TCP SACK retransmission queue fragmentation DoS via…

01 · The Real Story

A malicious download client that forces a file server to shred its outgoing mail into millions of confetti pieces until it runs out of desk space

CVE-2019-11478 is a Linux kernel TCP retransmission queue flaw in tcp_fragment. A remote attacker can act as a TCP receiver and send crafted TCP Selective Acknowledgment (SACK) sequences to force a vulnerable Linux sender to split queued data into thousands of tiny socket buffers (skbs), inflating memory usage and potentially overflowing 32-bit counters. Affected kernels are those before upstream stable fixes: 4.4.182, 4.9.182, 4.14.127, 4.19.52, and 5.1.11, plus distro kernels without the backport of commit f070ef2ac66716357066b683fb0baf55f8191a2e.

Vendor severity is HIGH 7.5. For internet-facing Linux servers in 2019 this was fair — a no-auth remote DoS against a widely deployed TCP stack. In 2026, most supported kernels carry the fix, the impact is pure availability, and no data loss or code execution is possible, so a blanket HIGH overstates the patch burden for a typical 10,000-host fleet.

Bottom line: For a MEDIUM verdict, the noisgate mitigation SLA is no mitigation SLA — go straight to the noisgate remediation SLA of ≤ 365 days. Prioritize any internet-facing legacy Linux host still running a pre-2019 kernel; for the rest, treat this as a routine kernel update during normal maintenance windows.

"Remote unauthenticated TCP DoS via SACK queue fragmentation, but no data loss and six-year-old patches make this a hygiene issue for most fleets."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Locate a reachable TCP data stream

The attacker only needs a network path to any Linux host running a vulnerable kernel that serves TCP data. Common candidates are web servers transferring large files, legacy FTP servers, API endpoints returning large responses, or any service that will send a substantial amount of data to a client. The vulnerability targets the sender's retransmission queue, so the victim must act as the sender of a non-trivial payload.

Conditions required:

Network path to a vulnerable Linux TCP service that emits data
Attacker can complete a TCP handshake and act as a receiver

Where this breaks in practice:

Perimeter firewalls and load balancers often restrict direct access to Linux app servers
Many services require authentication before returning large responses, though some public endpoints do not

Detection/coverage: No practical passive IDS/IPS signature reliably detects and blocks crafted SACK sequences in production.

STEP 02

Trigger a large sender-side transfer

For HTTP, the attacker requests a large static file or API response; for other protocols, they request enough data to fill the TCP send queue. The victim kernel allocates up to sk_sndbuf bytes for the socket, creating a queue that can later be fragmented. This step is necessary because tcp_fragment operates on queued outgoing data.

Conditions required:

Victim application is willing to send a large payload to the unauthenticated attacker
TCP receive window remains open enough to cause retransmissions

Where this breaks in practice:

WAF/L7 proxies may cap response sizes, stream responses, or cache/compress content
Backend apps often buffer or chunk responses, limiting queue depth

Detection/coverage: Standard DDoS/rate-limit tools may observe large outbound transfers but not necessarily malicious SACK behavior.

STEP 03

Fire crafted SACK sequences at the sender

By selectively acknowledging scattered bytes, the attacker forces the kernel to repeatedly fragment queued data into small SKBs. The upstream fix f070ef2ac66716357066b683fb0baf55f8191a2e added sane memory limits on when tcp_fragment may split. Without that fix, each split allocates SKB overhead, inflating memory usage and potentially overflowing 32-bit counters. Public PoC tooling such as Scapy scripts or custom C code can generate the required TCP segments.

Conditions required:

Vulnerable kernel without the f070ef2ac667 backport
Attacker can send crafted TCP segments, e.g., via Scapy or a raw socket

Where this breaks in practice:

Container cgroup memory limits may kill the process before host OOM
Kernel tcp_mem pressure can limit global TCP memory
Modern kernels backport the sane memory limit and are not affected

Detection/coverage: eBPF/tracing can observe unusually high SKB fragmentation; kernel SNMP counters may show the new fallback counter added by the fix.

STEP 04

Consume kernel memory and degrade the service

The inflated retransmission queue consumes kernel memory, causing OOM kills of the affected service, high CPU from SKB overhead, or host-wide memory pressure. A single connection may only degrade the service temporarily, but repeated or concurrent connections can keep the host under pressure and extend the outage.

Conditions required:

Victim host has limited or unmonitored memory
Attacker maintains multiple concurrent connections to exhaust resources

Where this breaks in practice:

OOM killer may kill the affected process but not the kernel, though host memory pressure remains
Autoscaling or process restarts can recover, but repeated attacks prolong outage

Detection/coverage: Monitoring of kernel memory, TCP memory, and OOM events can detect after incident; no reliable pre-exploit signature.

STEP 05

Maintain the DoS condition

An attacker can script repeated large transfers and crafted SACK sequences to keep memory pressure high. Public proof-of-concept code from the 2019 SACK panic wave automates this. Without a patch, the target remains re-exploitable indefinitely.

Conditions required:

Target remains unpatched
Attacker retains network access to the vulnerable service

Where this breaks in practice:

Network ACLs or rate limiting may drop anomalous TCP streams
Patched kernels ignore oversized fragmentation and stop the attack

Detection/coverage: Netflow/EDR baselines may detect sustained abnormal outbound/CPU patterns over time.

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Patch the kernel to the fixed backport or upstream commit f070ef2ac66716357066b683fb0baf55f8191a2e — Apply the vendor kernel update that matches your distribution; this closes the retransmit queue fragmentation path permanently. Deploy within 365 days per the noisgate remediation SLA for MEDIUM severity — no mitigation SLA is mandated.

MEDIUM 5.5→MEDIUM 4.0

Restrict network exposure to TCP services — Use host firewalls, security groups, or network ACLs to limit who can initiate connections to Linux services. This shrinks the attack surface to internal or trusted sources only. Defense-in-depth; rollout alongside the patch within 365 days.

MEDIUM 5.5→MEDIUM 4.5

Tune TCP memory pressure and cgroup/container memory limits — Set kernel tcp_mem and container memory limits so excessive SKB overhead kills the affected process rather than exhausting host memory. This limits blast radius but does not stop the attack. Apply as hardening during regular maintenance.

What doesn't work

Disabling TCP SACK system-wide via net.ipv4.tcp_sack=0 may reduce the SACK abuse window but hurts throughput and may not cover all fragmentation paths; use only as a last-resort interim control.
Relying on IDS/IPS signatures to block crafted SACK packets — sequence numbers and TCP options can be varied, so reliable pre-detect is impractical.
Restarting affected services without patching — the attacker can immediately re-trigger the memory exhaustion, and the kernel remains vulnerable.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No confirmed active exploitation campaign; not listed in CISA KEV. The 2019 SACK panic wave generated public PoCs, but no current mass exploitation.
Proof-of-concept	Public PoCs for the SACK Slowness/Panic family circulated in 2019. Search GitHub repositories for CVE-2019-11478 shows mostly unmaintained scripts.
EPSS score	0.94686 (94.7th percentile) — a high predicted likelihood of exploitation if an exposed host remains unpatched.
KEV status	Not listed in CISA KEV as of this assessment; no KEV deadline override applies.
CVSS vector	`CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` — network, low complexity, no privileges, no user interaction, availability only.
Affected version ranges	Linux kernel before 4.4.182, 4.9.182, 4.14.127, 4.19.52, and 5.1.11; some distro kernels have different backport status.
Fixed versions	Upstream commit `f070ef2ac66716357066b683fb0baf55f8191a2e`; distro backports include Debian DSA-4465-1, DLA-1823-1, DLA-1824-1, Red Hat, Ubuntu, and SUSE.
Scanning/exposure data	Shodan/Censys cannot fingerprint kernel version directly; exposure is inferred from any reachable TCP service. In 2019 internet-wide scans found millions of hosts in affected ranges, but current exposure is much lower due to patching.
Disclosure date	2019-06-19, coordinated as part of the SACK Panic/Slowness disclosure.
Reporting researcher/org	Jonathan Looney (Netflix) reported the issue; Google's Eric Dumazet authored the upstream fix; coordinated via CERT/CC VU#905115.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Baseline audit: Vendor HIGH 7.5 presumes any network path to a sender-side TCP service; this is a remote unauthenticated DoS with low complexity.
Friction audit: Requires the victim to send a large data stream and the attacker to craft valid SACKs; many Linux app servers sit behind L7 reverse proxies that cap or file responses, and ACLs limit direct exposure.
Patch maturity: Upstream and distro fixes landed in 2019; vulnerable kernels today are legacy, unmanaged, or end-of-life systems, narrowing the real at-risk population.
Impact ceiling: Availability-only impact — no memory corruption, no credential theft, no lateral movement; host/service recovery is usually quick once the malicious connection stops.
Role multiplier: On Linux hypervisors or network-edge appliances a successful DoS can down multiple tenants or a site, but it does not achieve domain take-over, fleet code execution, data egress, or supply-chain compromise — so the noisgate high-value-role floor remains below HIGH.
EPSS/KEV split: EPSS 0.94686 is high, but no KEV listing and no current in-the-wild campaigns suggest exploitation is not actively occurring at scale.

Why not higher?

Not higher because the only impact is transient availability loss; the vulnerability grants no code execution, no privilege escalation, and no data access. The patch is six years old, so most supported Linux fleets already have it, and the remaining exposed population is largely lab, legacy, or unmanaged boxes rather than production infrastructure.

Why not lower?

Not lower because a remote attacker with no credentials can still reliably exhaust memory on any unpatched exposed Linux service that sends large data. In shared, hypervisor, or edge roles the resulting outage can be organization-wide, so it must not be treated as backlog hygiene.

06 · Verification

Crowdsourced verification payload.

Run on each Linux host directly, or via a management tool that can SSH to each Linux target, as root. Invoke: bash cve-2019-11478_check.sh. The script reads uname -r and checks against upstream fixed releases. For distro backports it may return UNKNOWN — then use the vendor advisory or package manager to confirm.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# CVE-2019-11478 mainline kernel version check
set -u

krel=$(uname -r)
echo "Kernel release: $krel"

ver_int() {
  echo "$1" | awk -F. '{gsub(/[^0-9].*/, "", $3); printf "%d%03d%03d", $1, $2, $3}'
}

k=$(ver_int "$krel")
if [ -z "$k" ]; then
  echo "UNKNOWN: unable to parse kernel version"
  exit 2
fi

major=$(echo "$krel" | awk -F. '{print $1}')
minor=$(echo "$krel" | awk -F. '{print $2}')

if [ "$major" -ge 5 ]; then
  if [ "$major" -eq 5 ] && [ "$minor" -le 1 ]; then
    if [ "$k" -ge "$(ver_int 5.1.11)" ]; then echo "PATCHED"; exit 0; else echo "VULNERABLE"; exit 1; fi
  else
    echo "PATCHED"; exit 0
  fi
elif [ "$major" -eq 4 ]; then
  case "$minor" in
    4) [ "$k" -ge "$(ver_int 4.4.182)" ] && { echo "PATCHED"; exit 0; } || { echo "VULNERABLE"; exit 1; } ;;
    9) [ "$k" -ge "$(ver_int 4.9.182)" ] && { echo "PATCHED"; exit 0; } || { echo "VULNERABLE"; exit 1; } ;;
    14) [ "$k" -ge "$(ver_int 4.14.127)" ] && { echo "PATCHED"; exit 0; } || { echo "VULNERABLE"; exit 1; } ;;
    19) [ "$k" -ge "$(ver_int 4.19.52)" ] && { echo "PATCHED"; exit 0; } || { echo "VULNERABLE"; exit 1; } ;;
    *) echo "UNKNOWN: 4.x branch not in fixed list; check distro backport"; exit 2 ;;
  esac
else
  echo "UNKNOWN: kernel older than 4.4 or unknown; check vendor"
  exit 2
fi