There seems to be an official statement by Red Hat now: https://access.redhat.com/articles/7132207

Oh that's surprising, it isn't behind a paywall.

> we would need need to recover disk partitions/LVM metadata, boot records, etc. as well as all the data itself.

While other suggested, image-based solutions better fit your bit-for-bit requirement, you might also be interested in ReaR: https://relax-and-recover.org/

ReaR generates a bootable image which performs all that basic partitioning and is able to trigger an actual system/application data file restore using a variety of tools (including borg).

ReaR is an awesome piece of software!

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

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. Thanks!

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.)

This mentions FreeBSD impacts as well which the RedHat link doesn't.

For FreeBSD only the RACK stack seems to be affected - that's an alternative TCP/IP stack, not the default one.

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.

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.

There is also an ansible playbook on the resolve tab to easily apply the net.ipv4.tpc_sack workaround on all your hosts.

With a typo ("tpc_sack" instead of "tcp_sack") in the task name. The playbook still works, but I found it chuckle-worthy. :)

Thanks for the report, getting our team to fix that.

I think this is related to kpatch only being available as of RHEL 7.2 [1] in general. In other words, this must not necessarily be caused by any specifics of the current kernel patches.

[1] https://access.redhat.com/articles/2475321#scope