7 ms·

Red Hat's article on these issues also provides further explanations: https://access.redhat.com/security/vulnerabilities/tcpsack https://access.redhat.com/secur

• dang 7y ago
  That seems to have a bit more information, so we switched to it from https://www.openwall.com/lists/oss-security/2019/06/17/5 https://www.openwall.com/lists/oss-security/2019/06/17/5. Thanks!
  • ilkkao 7y ago
    The original link includes links to the patches. Fascinating how the SACK MSS problem seems to be a relatively simple situation nobody realized can occur.
    • jandrese 7y ago
      You'd have to dig pretty deep to realize that the kernel structure is limited to just 17 entries, and then do the math with minimum packet sizes vs. header sizes.
  • loeg 7y ago
    https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md https://github.com/Netflix/security-bulletins/blob/master/ad... is the advisory by the party that discovered the issue. (Disclosure: I have met Jonathan Looney and know some of the Netflix engineering staff, but I don't work for Netflix.)
    • caf 7y ago
      This mentions FreeBSD impacts as well which the RedHat link doesn't.
      • trasz 7y ago
        For FreeBSD only the RACK stack seems to be affected - that's an alternative TCP/IP stack, not the default one.
• bauruine 7y ago
  There is also an ansible playbook on the resolve tab to easily apply the net.ipv4.tpc_sack workaround on all your hosts.
  • pferde 7y ago
    With a typo ("tpc_sack" instead of "tcp_sack") in the task name. The playbook still works, but I found it chuckle-worthy. :)
    • wademealing 7y ago
      Thanks for the report, getting our team to fix that.