Three vulnerabilities have been discovered in the FreeBSD and Linux kernels through which attackers could induce a denial-of-service by clogging networking I/O on affected systems.
Affecting all Linux distro kernels from 2.6.29 or later (March 2009 onwards), Looney describes it as:
A sequence of SACKs [that] may be crafted such that one can trigger an integer overflow, leading to a kernel panic.
SACK stands for Selective Acknowledgment, a feature introduced nearly two decades ago to help TCP performance when retransmitting packets.
‘Kernel panic’, meanwhile, is the Linux equivalent of what anyone who used Windows versions prior to XP will remember as a General Protection Fault (GPF), or Blue Screen of Death – in other words, a system crash.
The second, identified as CVE-2019-11478, is a related problem whereby an attacker might craft a sequence of SACKs that would cause excess resource usage in the TCP retransmission queue on all Linux versions.
On kernels earlier than 4.15, the same flaw could be exploited to cause ‘SACK Slowness’ delays, in effect amplifying the denial of service.
A variation of this, CVE-2019-5599, is identical to SACK Slowness but affects only FreeBSD 12 installations using the RACK TCP Stack.
The third and final bug, CVE-2019-11479, is about inducing increased bandwidth consumption through which…
An attacker can force the Linux kernel to segment its responses into multiple TCP segments, each of which contains only 8 bytes of data. This drastically increases the bandwidth required to deliver the same amount of data.
Patch v mitigate
The SACK Panic flaw can be fixed by applying PATCH_net_1_4.patch or, alternatively, mitigated by disabling SACK processing (
/proc/sys/net/ipv4/tcp_sack set to 0) whilst noting the possibility that this might break connections requiring a low Maximum Segment Size (MSS).
Additionally, kernel versions up to and including 4.14 require a second patch: PATCH_net_1a.patch.
For excess resource usage / SACK Slowness (CVE-2019-11478) the required fix is PATCH_net_2_4.patch, or by applying workaround mitigations such as disabling SACK processing.
For SACK Slowness (CVE-2019-5599) affecting FreeBSD, the mitigation is either to apply the split_limit.patch or temporarily disable the RACK TCP stack.
Apple’s macOS (which traces its lineage back to the Darwin FreeBSD port from NeXTSTEP days) isn’t mentioned anywhere in connection with the alert despite supporting SACKs. If we receive an update on that either way, we’ll publish further details.