CVE-2018-5391
Description
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.
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/.
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.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.5 | 7.5 | N/A |
| Attack Vector | Network | Network | N/A |
| Attack Complexity | Low | Low | N/A |
| Privileges Required | None | None | N/A |
| User Interaction | None | None | N/A |
| Scope | Unchanged | Unchanged | N/A |
| Confidentiality | None | None | N/A |
| Integrity Impact | None | None | N/A |
| Availability Impact | High | High | N/A |
Vector
Red Hat: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
NVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Understanding the Weakness (CWE)
Availability
Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)
If an attacker can trigger the allocation of the limited resources, but the number or size of the resources is not controlled, then the most common result is denial of service. This would prevent valid users from accessing the product, and it could potentially have an impact on the surrounding environment, i.e., the product may slow down, crash due to unhandled errors, or lock out legitimate users. For example, a memory exhaustion attack against an application could slow down the application as well as its host operating system.
Access Control,Other
Technical Impact: Bypass Protection Mechanism; Other
In some cases it may be possible to force the product to "fail open" in the event of resource exhaustion. The state of the product -- and possibly the security functionality - may then be compromised.
Acknowledgements
Red Hat would like to thank Juha-Matti Tilli (Aalto University - Department of Communications and Networking and Nokia Bell Labs) for reporting this issue.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
