Support Center > Search Results > SecureKnowledge Details
Check Point response to TCP SACK PANIC - Linux Kernel vulnerabilities - CVE-2019-11477, CVE-2019-11478 and CVE-2019-11479 Technical Level
  • Three related flaws were found in the Linux kernel's handling of TCP networking. The most severe vulnerability could allow a remote attacker to trigger a kernel panic in systems running the affected software and, as a result, impact the system's availability.



The Linux kernel is vulnerable to an integer overflow in the 16 bit width of TCP_SKB_CB(skb)->tcp_gso_segs. A remote attacker could exploit this to crash the system and create a Denial Of Service.


The Linux kernel is vulnerable to a flaw that allows attackers to send a crafted sequence of SACKs which will fragment the TCP retransmission queue. An attacker might be able to further exploit the fragmented queue to cause an expensive linked-list walk for subsequent SACKs received for that same TCP connection. This could cause the CPU to spend excessive time attempting to reconstruct the list creating a Denial Of Service.


The Linux kernel is vulnerable to a flaw that allows attackers to send a crafted packets with low MSS values to trigger excessive resource consumption. 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. Further, it consumes additional resources (CPU and NIC processing power). This attack requires continued effort from the attacker and the impacts will end shortly after the attacker stops sending traffic. While this attack is ongoing, the system will work at reduced capacity resulting in a Denial Of Service for some users.


After having inspected the vulnerabilities and relevant patches, the impact to Check Point products is narrowed down to the list below.

Note that Check Point cloud services on relevant platforms were already patched on 18-June-2019.



  • CVE-2019-11477 - The following releases are vulnerable:
    • R80.10 Security Management on Smart-1 appliances 
    • R80.20 Security Management 
    • R80.30 Security Management 
    • R80.20_3.10 (CloudGuard) 
    • R80.30_3.10 (16000/26000) 
    • R80.20SP + Maestro 
    • SMB (700/1400/1200R)

  • CVE-2019-11478 - All Check Point releases are vulnerable (as this already exists in Linux for many years).

  • CVE-2019-11479 - Check Point is not vulnerable to this CVE (Check Point do not compile with the vulnerable code).

The vulnerabilities are relevant for local connections only (established TCP connections to or from the Security Gateway).
Connections going through the Security Gateway for Deep Packet Inspection, and most connections to the Gateway Web Portals are not affected.


Fix in code

Gateways and Management

    • R77.30 Security Management and Gateway - Jumbo Hotfix Accumulator for R77.30 (R77_30_jumbo_hf) - Take_351 (and higher).

    • R80.10 Security Management and Gateway - Jumbo Hotfix Accumulator for R80.10 (R80_10_jumbo_hf) - Take_225 (and higher).

      For Smart-1 525 / 5050 / 5150 - Download and install R80.10 3.10 Kernel TCP SACK PANIC Hotfix
      The Hotfix should be installed on top of R80.10 JHF Take_203.

    • R80.20 Security Management  and Gateway - Jumbo Hotfix Accumulator for R80.20 (R80_20_jumbo_hf) – Take_87 (and higher).

      A new Hotfix
          , available on top of
      Jumbo Hotfix Accumulator for R80.20 Take 87
        , enables the Security Gateway to remove the SACK-permitted option from the TCP headers of packets passing through it, thereby protecting the hosts behind the Security Gateway from attacks using the SACK feature of TCP. The new global parameter provided in the Hotfix will, when set, force the Security Gateway to remove any existing SACK-permitted TCP option.

          To get the Hotfix, please
      Contact Support
        . After you install the Hotfix, do the following:

          1. In
        , add this line: tcp_sack_permitted_remove_option=1
          2. In
        , add this line: tcp_sack_permitted_remove_option=1
        3. Reboot the Security Gateway(s).

      Important Note
        : that removing the SACK-permitted option from the TCP headers can have a performance impact on the traffic passing through the gateway. The impact depends on the quantity of lost packets.

Lights out Management (LOM) cards 

  • 5100 / 5200 / 5400 / 5600 / 5800 / 5900 6500 / 6800 15400 / 15600 / 23500 / 23800 / 23900 Appliances - v3.35g

  • 13500 / 13800 21600 / 21700 / 21800 Smart-1 225 / Smart-1 3050 / Smart-1 3150 Appliances - v2.43n

  • 4800 / 12200 / 12400 / 12600 TE250 / TE1000 Appliances - v2.22

If you have applied the mitigation below, it is advised to reverse it after installing the fix.
To reverse, run:

echo 1 > /proc/sys/net/ipv4/tcp_sack

If you added the "#Disable TCP SACK" lines suggested below for making the changes persistent after reboot, remove them after installing the fix.



Until a code fix is available for the release you are using, it is advised to disable the TCP SACK feature system wise, at least for internet-facing machines.

Log in to Expert mode and run the following:

echo 0 > /proc/sys/net/ipv4/tcp_sack

In order to make the change persistent after reboot, add the following lines in /etc/rc.local (for SMB /pfrm2.0/etc/platformInit should be used instead of /etc/rc.local):

#Disable TCP SACK
sysctl -w net.ipv4.tcp_sack=0

Note: Disabling SACK can have an impact on performance (depending on the packet-loss rate) for the local connections only.


Scalable Platforms Appliances

For Scalable Platform Appliances (41000, 44000, 61000, 64000) use the following procedure:

  1. # g_all "echo 0 > /proc/sys/net/ipv4/tcp_sack"

  2. # cp /etc/rc.local /etc/rc.local.BKP

  3. # vi /etc/rc.local and add:

    #Disable TCP SACK
    sysctl -w net.ipv4.tcp_sack=0

  4. # asg_cp2blades /etc/rc.local
This solution is about products that are no longer supported and it will not be updated

Give us Feedback
Please rate this document