← Back to Feed CACHED · 2026-10-30 10:00:39 · CACHE_KEY CVE-2019-11479
CVE-2019-11479 · CWE-405 · Disclosed 2019-06-19

Linux kernel TCP resend queue fragmentation via hard-coded minimum MSS [remote DoS]

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like a toll booth that accepts pennies, the Linux TCP stack lets remote peers force millions of tiny accounting entries until the system stalls

CVE-2019-11479 is a TCP-layer denial-of-service in the Linux kernel. The effective minimum TCP MSS is hard-coded to 48 bytes, so a remote peer can force the retransmission queue into a huge number of tiny segments — especially when combined with crafted SACK blocks — driving kernel memory and CPU consumption high enough to OOM or soft-lockup the host. Affected kernels are 4.4.x < 4.4.182, 4.9.x < 4.9.182, 4.14.x < 4.14.127, 4.19.x < 4.19.52, and 5.1.x < 5.1.11; older unsupported branches are also affected.

The vendor/NVD rating of High 7.5 is appropriate. The attack is unauthenticated and remote, but it only causes availability loss — no code execution, no privilege escalation, no data disclosure. In practice, public-facing Linux servers and network-adjacent internal hosts are the meaningful target population, and the kernel TCP stack is difficult to shield with application-layer controls. That earns a High, not Critical.

"Remote unauthenticated attacker can exhaust kernel queues via tiny TCP MSS; patch the kernel, not just the app."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a reachable TCP service on a vulnerable Linux host

The attacker scans for any exposed TCP port — SSH, HTTPS, database, custom app — on a host running an affected kernel. No application-level bug is needed; the flaw is in the kernel TCP stack itself.
Conditions required:
  • Network reachability from attacker to at least one TCP port
  • Target runs an affected Linux kernel branch
Where this breaks in practice:
  • Firewall/security groups can restrict exposure to specific source ranges
  • Cloud load balancers may hide backend kernel versions
Detection/coverage: General port scans are visible in NetFlow/IDS, but individual scan packets are not CVE-specific.
STEP 02

Negotiate a deliberately tiny TCP MSS

During the TCP handshake the attacker advertises an MSS of 48 bytes or less. The victim kernel clamps it to the hard-coded minimum and configures a usable send/retransmit segment size at that tiny value.
Conditions required:
  • Attacker can complete a TCP handshake
  • No inline TCP proxy rewrites or clamps the MSS
Where this breaks in practice:
  • TCP-terminating load balancers or SYN proxies can re-originate connections with a normal MSS
  • Some edge firewalls can drop SYNs with suspiciously small MSS option values
Detection/coverage: TCP-aware IDS can catch SYN packets with MSS < 536, but default signatures often lack this check.
STEP 03

Fragment the retransmission queue with crafted SACKs

The attacker sends data and SACK blocks that force the kernel to track many holes and retransmission segments at the negotiated tiny MSS. The retransmit queue becomes fragmented into a very large number of small entries, consuming disproportionate memory and CPU.
Conditions required:
  • Vulnerable Linux kernel with unfixed SACK/retransmit queue logic
  • Attacker can generate enough SACK blocks and data to sustain the pattern
Where this breaks in practice:
  • Rate limiting and connection caps can slow the exhaustion rate
  • Ingress traffic shaping may reduce throughput but not the fundamental property
Detection/coverage: SACK-storm anomaly detection may alert, but many shops do not run it on east-west traffic.
STEP 04

Exhaust kernel resources to create host-level DoS

Repeated or concurrent connections cause kernel memory pressure, soft lockups, or OOM kills, taking the host or all containers/VMs on it offline. The attacker needs no credentials and no application-level exploit.
Conditions required:
  • Attacker can sustain multiple connections
  • No kernel live-patch or per-connection memory limits intervene
Where this breaks in practice:
  • Modern kernels with automated OOM tuning may kill only the offending workload
  • Containerized workloads may limit blast radius to a single pod if the host kernel remains stable
Detection/coverage: Kernel OOM messages, soft lockup traces, memory pressure alerts, and monitoring dashboards can reveal the attack.
03 · Compensating Control

1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor kernel update — Patch the kernel using your distro's backport for CVE-2019-11479. For HIGH verdict, noisgate remediation SLA says apply the actual vendor patch within 180 days; use the mitigation SLA guides below only as temporary stopgaps if patching is delayed.
2
HIGH 7.5→MEDIUM 6.5
SEVERITY REDUCED
Drop SYNs advertising MSS below 536 at ingress — Use nftables on the INPUT path to match tcp option maxseg size 1-535 and drop. This stops remote peers from negotiating the tiny MSS that makes the retransmit queue fragment. Deploy within 30 days as a HIGH-severity stopgap.
3
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Restrict Linux TCP service exposure to trusted networks — Segment management/data planes and use firewall allowlists so untrusted remote peers cannot reach vulnerable kernel TCP stacks. Deploy within 30 days for HIGH severity.
4
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Terminate client TCP at a proxy or load balancer — HAProxy, nginx, or cloud load balancers that terminate TCP and re-originate to backends with normal MSS remove direct kernel TCP exposure. Deploy within 30 days if you cannot patch directly.
What doesn't work
  • Application-layer WAF rules — MSS and SACK are negotiated at the TCP layer, below the HTTP payload a WAF inspects.
  • FORWARD-chain TCPMSS clamping — that only adjusts forwarded traffic, not locally terminated TCP connections; use nftables INPUT rules or a TCP proxy instead.
  • Generic SYN cookies alone — they mitigate SYN floods but do not stop a completed connection from negotiating a tiny MSS and sending crafted SACKs.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusNot in CISA KEV; no sustained mass exploitation campaign documented. Public DoS PoCs circulated immediately after disclosure.
Proof-of-concept availabilityPublic PoC scripts and packet traces exist. See pocindex.io and GitHub searches for CVE-2019-11479 / SACK DoS reproducers.
EPSS0.9166 (91.66% 30-day probability; ~99th percentile). Extremely high likelihood model score for unpatched internet-facing Linux.
KEV statusNot listed in CISA KEV as of this assessment.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — network, low complexity, unauthenticated, availability impact only.
Affected versionsLinux kernel 4.4.x < 4.4.182, 4.9.x < 4.9.182, 4.14.x < 4.14.127, 4.19.x < 4.19.52, 5.1.x < 5.1.11; older unsupported branches also affected.
Fixed versions4.4.182, 4.9.182, 4.14.127, 4.19.52, 5.1.11; distro backports in RHEL/CentOS, Ubuntu, Debian, SUSE, and others.
Scanning/exposureNot routinely detectable by Shodan/Censys because kernel version is not exposed; exposure equals any reachable TCP service on a vulnerable host. No broad scanning wave observed at disclosure.
Disclosure date / researcher2019-06-19; Jonathan Looney, Netflix.

Sources.

  1. NVD
  2. CVE.org
  3. Ubuntu Security
  4. Red Hat CVE
  5. Debian Security Tracker
  6. Kernel commit 967c05aee439
  7. PoC Index
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

Why this verdict

  • Baseline: vendor/NVD 7.5 High is a fair starting point: unauthenticated remote exploitation with low complexity and high availability impact.
  • Friction audit: the only hard prerequisite is reachability to any TCP port on a vulnerable Linux host. Load balancers, TCP proxies, and strict firewalls blunt it, but many bare-metal and VM servers still expose TCP directly.
  • Role multiplier: Linux is the kernel for hypervisors, databases, edge proxies, Kubernetes nodes, and network appliances. A successful DoS can take a production node or service offline, but the outcome is availability-only — not domain takeover, fleet compromise, or supply-chain pivot.
  • EPSS: 0.9166 indicates a high probability of exploitation attempts against internet-facing unpatched Linux hosts, keeping pressure against downgrading to MEDIUM.

Why not higher?

The attack only causes availability loss on the targeted host; it never grants code execution, reads memory, or escalates privileges. The attacker must re-attack each exposed host independently, and the blast radius is bounded per connection — no lateral movement, no data egress, no credential theft.

Why not lower?

The attacker is unauthenticated and remote, requiring no user interaction or credentials. Linux is ubiquitous in servers, cloud workloads, and network appliances, so even a single-host kernel OOM qualifies as a production incident on high-value roles. Public PoCs and very high EPSS argue against MEDIUM for internet-facing footprints.

06 · Verification

Crowdsourced verification payload.

Run on each Linux host you suspect may be unpatched. Save the script as check_cve_2019_11479.sh and invoke with bash check_cve_2019_11479.sh. No special privileges are required for kernel version checks; root helps read package changelogs for backport detection.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# CVE-2019-11479 checker - Linux TCP small-MSS DoS (SACK resource exhaustion)
# Usage: bash cve-2019-11479.sh
# Run on the Linux host to be checked; any user can run, root only helps read package changelogs.
set -u

kver="$(uname -r)"
echo "Kernel version: $kver" >&2

# Try distro changelog/backport metadata first.
patched_by_changelog=false
if command -v rpm >/dev/null 2>&1; then
  for p in $(rpm -qa 'kernel*' 2>/dev/null); do
    if rpm -q --changelog "$p" 2>/dev/null | grep -qi 'CVE-2019-11479'; then
      patched_by_changelog=true; break
    fi
  done
fi
if command -v dpkg >/dev/null 2>&1; then
  for cl in /usr/share/doc/linux-image-${kver}/changelog* /usr/share/doc/linux-image-$(uname -r)/changelog*; do
    [ -f "$cl" ] || continue
    if zgrep -qi 'CVE-2019-11479' "$cl" 2>/dev/null || grep -qi 'CVE-2019-11479' "$cl" 2>/dev/null; then
      patched_by_changelog=true; break
    fi
  done
fi
if $patched_by_changelog; then
  echo "PATCHED"; exit 0
fi

kbase="$(echo "$kver" | grep -oE '^[0-9]+\.[0-9]+\.[0-9]+' || echo "$kver")"
version_ge() { [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -1)" = "$2" ]; }
version_lt() { ! version_ge "$1" "$2"; }

# Known mainline fixed versions.
if version_ge "$kbase" "5.1.11"; then echo "PATCHED"; exit 0; fi
if version_ge "$kbase" "4.19.52" && version_lt "$kbase" "4.20"; then echo "PATCHED"; exit 0; fi
if version_ge "$kbase" "4.14.127" && version_lt "$kbase" "4.15"; then echo "PATCHED"; exit 0; fi
if version_ge "$kbase" "4.9.182" && version_lt "$kbase" "4.10"; then echo "PATCHED"; exit 0; fi
if version_ge "$kbase" "4.4.182" && version_lt "$kbase" "4.5"; then echo "PATCHED"; exit 0; fi

# Explicitly vulnerable longterm branches below their fixed version.
if version_ge "$kbase" "4.4" && version_lt "$kbase" "4.5" && version_lt "$kbase" "4.4.182"; then echo "VULNERABLE"; exit 1; fi
if version_ge "$kbase" "4.9" && version_lt "$kbase" "4.10" && version_lt "$kbase" "4.9.182"; then echo "VULNERABLE"; exit 1; fi
if version_ge "$kbase" "4.14" && version_lt "$kbase" "4.15" && version_lt "$kbase" "4.14.127"; then echo "VULNERABLE"; exit 1; fi
if version_ge "$kbase" "4.19" && version_lt "$kbase" "4.20" && version_lt "$kbase" "4.19.52"; then echo "VULNERABLE"; exit 1; fi
if version_ge "$kbase" "5.1" && version_lt "$kbase" "5.2" && version_lt "$kbase" "5.1.11"; then echo "VULNERABLE"; exit 1; fi

# Distro kernels with missing changelog data: cannot confirm.
echo "UNKNOWN"; exit 2