Bug 1609664 (CVE-2018-5391, FragmentSmack) - CVE-2018-5391 kernel: IP fragments with random offsets allow a remote denial of service (FragmentSmack)
Summary: CVE-2018-5391 kernel: IP fragments with random offsets allow a remote denial ...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-5391, FragmentSmack
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1613923 1613924 1613925 1613926 1613927 1613928 1613929 1613930 1615773 1615774 1615775 1615776 1615777 1615778 1615779 1616058 1616059 1619083
Blocks: 1599112 1612952 1612953 1612954 1612955
TreeView+ depends on / blocked
 
Reported: 2018-07-30 07:11 UTC by Sam Fowler
Modified: 2023-09-25 06:01 UTC (History)
72 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
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 algorithm by sending specially crafted packets which could lead to a CPU saturation and hence a denial of service on the system.
Clone Of:
Environment:
Last Closed: 2019-03-05 14:08:07 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:2785 0 None None None 2018-09-25 20:44:25 UTC
Red Hat Product Errata RHSA-2018:2791 0 None None None 2018-09-25 20:24:00 UTC
Red Hat Product Errata RHSA-2018:2846 0 None None None 2018-10-09 15:49:58 UTC
Red Hat Product Errata RHSA-2018:2924 0 None None None 2018-10-16 14:50:00 UTC
Red Hat Product Errata RHSA-2018:2925 0 None None None 2018-10-16 23:54:12 UTC
Red Hat Product Errata RHSA-2018:2933 0 None None None 2018-10-16 18:55:29 UTC
Red Hat Product Errata RHSA-2018:2948 0 None None None 2018-10-30 09:04:42 UTC
Red Hat Product Errata RHSA-2018:3083 0 None None None 2018-10-30 07:35:53 UTC
Red Hat Product Errata RHSA-2018:3096 0 None None None 2018-10-30 07:41:54 UTC
Red Hat Product Errata RHSA-2018:3459 0 None None None 2018-11-06 15:31:19 UTC
Red Hat Product Errata RHSA-2018:3540 0 None None None 2018-11-13 16:33:21 UTC
Red Hat Product Errata RHSA-2018:3586 0 None None None 2018-11-13 16:31:04 UTC
Red Hat Product Errata RHSA-2018:3590 0 None None None 2018-11-13 17:50:37 UTC

Description Sam Fowler 2018-07-30 07:11:26 UTC
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

Comment 1 Sam Fowler 2018-07-30 07:11:44 UTC
Acknowledgments:

Name: Juha-Matti Tilli (Aalto University - Department of Communications and Networking and Nokia Bell Labs)

Comment 13 Vladis Dronov 2018-08-08 10:09:14 UTC
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.

Comment 16 Vladis Dronov 2018-08-14 20:09:40 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1616059]

Comment 18 Vladis Dronov 2018-08-14 21:28:07 UTC
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/.

Comment 19 Hal Murphy 2018-08-14 23:34:33 UTC
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

Comment 20 Hal Murphy 2018-08-14 23:36:16 UTC
Typo: low_thresh is HIGHER than high_thresh

Comment 21 Vladis Dronov 2018-08-15 08:02:08 UTC
(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.

Comment 22 Justin M. Forbes 2018-08-15 20:07:43 UTC
This was fixed for Fedora with the 4.17.13 stable kernel updates.

Comment 24 hayg 2018-08-30 00:12:29 UTC
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.

Comment 25 Frank Liu 2018-08-30 07:28:58 UTC
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.

Comment 26 Vladis Dronov 2018-08-30 21:34:52 UTC
(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.

Comment 27 hayg 2018-08-31 01:03:49 UTC
Nice! Thanks for the confirmation Vladis. I'm becoming more and more convinced we should switch to Redhat ;)

Comment 28 Frank Liu 2018-09-21 14:59:14 UTC
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.

Comment 33 Vladis Dronov 2018-09-25 11:03:44 UTC
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.

Comment 34 Frank Liu 2018-09-25 20:21:28 UTC
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

Comment 35 errata-xmlrpc 2018-09-25 20:23:36 UTC
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

Comment 36 errata-xmlrpc 2018-09-25 20:43:59 UTC
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

Comment 37 Vladis Dronov 2018-09-28 17:52:16 UTC
(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.

Comment 38 Frank Liu 2018-09-29 00:18:25 UTC
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.

Comment 39 Vladis Dronov 2018-10-04 14:03:24 UTC
(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".

Comment 40 errata-xmlrpc 2018-10-09 15:49:29 UTC
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

Comment 41 errata-xmlrpc 2018-10-16 14:49:14 UTC
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

Comment 42 errata-xmlrpc 2018-10-16 18:55:01 UTC
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

Comment 43 errata-xmlrpc 2018-10-16 23:53:45 UTC
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

Comment 44 Guy G 2018-10-23 16:48:30 UTC
Would upgrading to RHEL 7.5 solve the issue? Is the Kernel already updated?
Can anyone help please?

Comment 45 errata-xmlrpc 2018-10-30 07:35:26 UTC
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

Comment 46 errata-xmlrpc 2018-10-30 07:41:27 UTC
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

Comment 47 errata-xmlrpc 2018-10-30 09:04:15 UTC
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

Comment 48 Vladis Dronov 2018-10-31 16:02:46 UTC
(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).

Comment 50 errata-xmlrpc 2018-11-06 15:30:47 UTC
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

Comment 52 errata-xmlrpc 2018-11-13 16:30:36 UTC
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

Comment 53 errata-xmlrpc 2018-11-13 16:32:53 UTC
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

Comment 54 errata-xmlrpc 2018-11-13 17:50:12 UTC
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


Note You need to log in before you can comment on or make changes to this bug.