A flaw named FragmentSmack was found in the way the Linux kernel handled reassembly of fragmented IPv4 and IPv6 packets. A remote attacker could use this flaw to trigger time and calculation expensive fragment reassembly algorithms by sending specially crafted packets which could lead to a CPU saturation and hence a denial of service on the system. External References: https://access.redhat.com/articles/3553061 https://www.kb.cert.org/vuls/id/641765 A fix is a merge commit in the Linux kernel tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c30f1fc041b74ecdb072dd44f858750414b8b19f consisting of the following commits: 7969e5c40dfd04799d4341f1b7cd266b6e47f227 385114dec8a49b5e5945e77ba7de6356106713f4 fa0f527358bd900ef92f925878ed6bfbd51305cc
Acknowledgments: Name: Juha-Matti Tilli (Aalto University - Department of Communications and Networking and Nokia Bell Labs)
Mitigation: One may change the default 4MB and 3MB values of net.ipv4.ipfrag_high_thresh and net.ipv4.ipfrag_low_thresh (and their ipv6 counterparts net.ipv6.ipfrag_high_thresh and net.ipv6.ipfrag_low_thresh) to 256 kB and 192 kB (respectively) or below. Tests show some to significant CPU saturation drop during an attack, depending on a hardware, configuration and environment. There can be some impact on performance though, due to ipfrag_high_thresh of 262144 bytes, as only two 64K fragments can fit in the reassembly queue at the same time. For example, there is a risk of breaking applications that rely on large UDP packets. See the Mitigation section in the https://access.redhat.com/articles/3553061 article for the script to quickly change to/from default and lower settings.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1616059]
Statement: Red Hat Product Security is aware of this issue. Updates will be released as they become available. For additional information, please refer to the Red Hat Knowledgebase article: https://access.redhat.com/articles/3553061 This issue affects the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 6, 7, its real-time kernel, Red Hat Enterprise MRG 2, Red Hat Enterprise Linux 7 for ARM 64, and Red Hat Enterprise Linux 7 for Power 9. Future kernel updates for the respective releases will address this issue. This issue affects the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, but to a lesser degree. As such, the issue severity for RHEL5 is considered Moderate. This is not currently planned to be addressed in future updates of the product due to its life cycle and the issue severity. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.
I think the proposed new values in script at bottom of https://access.redhat.com/articles/3553061 are flipped: low_thresh is lower than high_thresh: sysctl -w net.ipv4.ipfrag_low_thresh=262144 sysctl -w net.ipv4.ipfrag_high_thresh=196608 sysctl -w net.ipv6.ip6frag_low_thresh=262144 sysctl -w net.ipv6.ip6frag_high_thresh=196608
Typo: low_thresh is HIGHER than high_thresh
(In reply to Hal Murphy from comment #20) > Typo: low_thresh is HIGHER than high_thresh Indee, this is wrong, thank you for noticing! The article was just fixed to provide correct values.
This was fixed for Fedora with the 4.17.13 stable kernel updates.
Has Redhat taken into account the update from CERT? https://www.kb.cert.org/vuls/id/641765 says: "Update: Further testing shows that these mitigations are not a 100% fix. A significantly strong attack will still result in a denial of service condition." In my own testing the memory mitigations are not a sufficient fix. It appears only the inclusion of this commit truly fixes the problem: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=c30f1fc041b74ecdb072dd44f858750414b8b19f I'm seeing this being largely ignored by Debian for example and I'm afraid that Redhat may not be aware either.
Looking at this bugzilla ticket, there have been no update for weeks. I have to agree with you that this bug is not treated as serious.
(In reply to hayg from comment #24) > In my own testing the memory mitigations are not a sufficient fix. as the "Mitigation:" (Comment#13) section and https://access.redhat.com/articles/3553061 mention, "Tests show some to significant CPU saturation drop during an attack, depending on a hardware, configuration and environment". so, yes, a mitigation is not a complete fix. > It appears only the inclusion of this commit truly fixes the problem: > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/ > ?id=c30f1fc041b74ecdb072dd44f858750414b8b19f as the "Description" (Comment#0) section mentions, "A fix is a merge commit in the Linux kernel tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c30f1fc041b74ecdb072dd44f858750414b8b19f". so, yes, this merge commit is considered as a fix for the flaw. the fix is currently being included in the Red Hat's products.
Nice! Thanks for the confirmation Vladis. I'm becoming more and more convinced we should switch to Redhat ;)
It's been almost 2 months since comment#0 , is the upstream fix not good enough and Red Hat developing a new one? Or is it vulnerability not as significant? I see most other distributions, including Fedora, have already issued the fix, using upstream patch.
The fix for this flaw is scheduled to be released in the next kernel update of RHEL-6 and RHEL-7. Please, note, Bugzilla is not a support tool. Please, open a support case on the Red Hat Customer Portal regarding resolution of this flaw.
Thanks Vladis for the update. BTW, I just saw the "next" kernel update just came out today: https://access.redhat.com/errata/RHSA-2018:2748
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.4 Advanced Update Support Via RHSA-2018:2791 https://access.redhat.com/errata/RHSA-2018:2791
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Extended Update Support Via RHSA-2018:2785 https://access.redhat.com/errata/RHSA-2018:2785
(In reply to Frank Liu from comment #34) > BTW, I just saw the "next" kernel update just came out today: > https://access.redhat.com/errata/RHSA-2018:2748 there is probably a wording issue. i've meant the next scheduled kernel, and RHSA-2018:2748 is out-of-order/emergency release which fixes a single impact=Important flaw CVE-2018-14634. FragmentSmack has a mitigation available, so it was decided to fix it in the in-order kernel.
Thanks for confirming my comment#28 about this vulnerability not as significant. Initially I thought due to comment#24 , the available mitigation is not a 100% fix and dos still happens.
(In reply to Frank Liu from comment #38) > the available mitigation is not a 100% > fix and dos still happens. yes, unfortunately, this mitigation is not a 100% fix, as "Tests show some to significant CPU saturation drop during an attack, depending on a hardware, configuration and environment".
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2018:2846 https://access.redhat.com/errata/RHSA-2018:2846
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Advanced Update Support Red Hat Enterprise Linux 6.6 Telco Extended Update Support Via RHSA-2018:2924 https://access.redhat.com/errata/RHSA-2018:2924
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 Advanced Update Support Via RHSA-2018:2933 https://access.redhat.com/errata/RHSA-2018:2933
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.7 Extended Update Support Via RHSA-2018:2925 https://access.redhat.com/errata/RHSA-2018:2925
Would upgrading to RHEL 7.5 solve the issue? Is the Kernel already updated? Can anyone help please?
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:3083 https://access.redhat.com/errata/RHSA-2018:3083
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:3096 https://access.redhat.com/errata/RHSA-2018:3096
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:2948 https://access.redhat.com/errata/RHSA-2018:2948
(In reply to Guy G from comment #44) > Would upgrading to RHEL 7.5 solve the issue? Is the Kernel already updated? > Can anyone help please? Hello, Unfortunately, no, RHEL-7.5 is vulnerable to this flaw as of now. Please, use the recent release of RHEL-7.6 which has this flaw fixed (see comments 45-47).
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.5 Extended Update Support Via RHSA-2018:3459 https://access.redhat.com/errata/RHSA-2018:3459
This issue has been addressed in the following products: Red Hat Enterprise MRG 2 Via RHSA-2018:3586 https://access.redhat.com/errata/RHSA-2018:3586
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Extended Update Support Via RHSA-2018:3540 https://access.redhat.com/errata/RHSA-2018:3540
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Advanced Update Support Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions Red Hat Enterprise Linux 7.2 Telco Extended Update Support Via RHSA-2018:3590 https://access.redhat.com/errata/RHSA-2018:3590