FreeBSD Kernel IP Fragment Reassembly Algorithm Lets Remote Users Consume Excessive Resources on the Target System
SecurityTracker Alert ID: 1041505|
SecurityTracker URL: http://securitytracker.com/id/1041505
(Links to External Site)
Date: Aug 16 2018
Denial of service via network|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 11.1, 11.2|
A vulnerability was reported in FreeBSD Kernel. A remote user can consume excessive resources on the target system.|
The system uses an inefficient IP fragment reassembly algorithm. A remote user can send specially crafted fragmented data to consume excessive CPU resources or mbuf clusters on the target system.
Both IPv4 and IPv6 processing is affected.
Juha-Matti Tilli (Aalto University, Department of Communications and Networking / Nokia Bell Labs) reported this vulnerability.
A remote user can consume excessive CPU resources or mbuf clusters on the target system.|
FreeBSD has issued a fix.|
The FreeBSD advisory is available at:
Vendor URL: security.FreeBSD.org/advisories/FreeBSD-SA-18:10.ip.asc (Links to External Site)
Source Message Contents
Subject: FreeBSD Security Advisory FreeBSD-SA-18:10.ip|
-----BEGIN PGP SIGNED MESSAGE-----
FreeBSD-SA-18:10.ip Security Advisory
The FreeBSD Project
Topic: Resource exhaustion in IP fragment reassembly
Credits: Juha-Matti Tilli <firstname.lastname@example.org> from
Aalto University, Department of Communications and Networking
and Nokia Bell Labs
Affects: All supported versions of FreeBSD.
Corrected: 2018-08-14 18:17:05 UTC (stable/11, 11.1-STABLE)
2018-08-15 02:30:11 UTC (releng/11.2, 11.2-RELEASE-p2)
2018-08-15 02:30:11 UTC (releng/11.1, 11.1-RELEASE-p13)
CVE Name: CVE-2018-6923
Special note: Due to source code differences in FreeBSD 10-stable a patch
is not yet available for FreeBSD 10.4. This will follow at
a later date.
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.
The Internet Protocol (IP) version 4 (IPv4) allows fragmentation of
packets which are too big to traverse all the links between two end
stations. Any router along the path between two end hosts may fragment
packets which are larger than a link's maximum transmission unit
(MTU). FreeBSD's implementation of some IPv4 protocols (such as the
Transmission Control Protocol [TCP]) perform path MTU discovery to
avoid the need for fragmentation.
IP version 6 (IPv6) retains the concept of packet fragmentation. It
changed the fragmentation operation to require that the originating
end-system perform path MTU discovery and fragment packets which are
too large for any MTU along the path between two end systems.
While all hosts attached to the Internet are required to support
fragmentation and reassembly, many hosts will encounter very few
legitimate fragmented packets due to the operation of path MTU discovery.
II. Problem Description
A researcher has notified us of a DoS attack applicable to another
operating system. While FreeBSD may not be vulnerable to that exact
attack, we have identified several places where inadequate DoS protection
could allow an attacker to consume system resources.
It is not necessary that the attacker be able to establish two-way
communication to carry out these attacks. These attacks impact both
IPv4 and IPv6 fragment reassembly.
In the worst case, an attacker could send a stream of crafted
fragments with a low packet rate which would consume a substantial
amount of CPU.
Other attack vectors allow an attacker to send a stream of crafted
fragments which could consume a large amount of CPU or all available
mbuf clusters on the system.
These attacks could temporarily render a system unreachable through
network interfaces or temporarily render a system unresponsive. The
effects of the attack should clear within 60 seconds after the attack stops.
Disable fragment reassembly, using these commands:
% sysctl net.inet.ip.maxfragpackets=0
% sysctl net.inet6.ip6.maxfrags=0
On systems compiled with VIMAGE, these sysctls will need to be
executed for each VNET.
Upgrade your vulnerable system to a supported FreeBSD stable or release or
security branch (releng) dated after the correction date, and reboot.
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Afterward, reboot the system.
2) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
Afterward, reboot the system.
3) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch https://security.FreeBSD.org/patches/SA-18:10/ip.patch
# fetch https://security.FreeBSD.org/patches/SA-18:10/ip.patch.asc
# gpg --verify ip.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
VI. Correction details
The following list contains the correction revision numbers for each
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.9 (FreeBSD)
-----END PGP SIGNATURE-----
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"