-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-26:06.tcp Security Advisory
The FreeBSD Project
Topic: TCP: remotely exploitable DoS vector (mbuf leak)
Category: core
Module: tcp
Announced: 2026-03-26
Credits: Michael Tuexen (Netflix)
Affects: FreeBSD 14.x and FreeBSD 15.0
Corrected: 2026-03-26 01:25:22 UTC (stable/15, 15.0-STABLE)
2026-03-26 01:11:18 UTC (releng/15.0, 15.0-RELEASE-p5)
2026-03-26 01:28:46 UTC (stable/14, 14.4-STABLE)
2026-03-26 01:14:54 UTC (releng/14.4, 14.4-RELEASE-p1)
2026-03-26 01:16:00 UTC (releng/14.3, 14.3-RELEASE-p10)
CVE Name: CVE-2026-4247
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
The Transmission Control Protocol (TCP) is a connection oriented transport
protocol, which can be used as an upper layer of IP.
When unexpected TCP segments are received for an established TCP connection,
so called "challenge ACK" segments may be sent back in response if certain
criteria are met.
Challenge ACKs are rate limited to ensure the remote peer does not waste too
many CPU cycles or outbound bandwidth on the local peer if large numbers of
unexpected TCP segments are received.
The rate limiting is controlled by the net.inet.tcp.ack_war_timewindow and
net.inet.tcp.ack_war_cnt sysctls which default to 1000 (milliseconds) and 5
respectively i.e. challenge ACKs will be sent for the first 5 qualifying TCP
segments received within a 1s time period and the rest will be ignored.
The handling of challenge ACKs is common code in tcp_subr.c shared among the
different TCP stacks available in the system. This includes the FreeBSD
default, RACK and BBR stacks. There are differences in the behaviour of the
different stacks; e.g. the base FreeBSD stack sends challenge ACKs to a larger
set of unexpected packets.
II. Problem Description
When a challenge ACK is to be sent tcp_respond() constructs and sends the
challenge ACK and consumes the mbuf that is passed in. When no challenge ACK
should be sent the function returns and leaks the mbuf.
III. Impact
If an attacker is either on path with an established TCP connection, or can
themselves establish a TCP connection, to an affected FreeBSD machine, they
can easily craft and send packets which meet the challenge ACK criteria and
cause the FreeBSD host to leak an mbuf for each crafted packet in excess of
the configured rate limit settings i.e. with default settings, crafted packets
in excess of the first 5 sent within a 1s period will leak an mbuf.
Technically, off-path attackers can also exploit this problem by guessing the
IP addresses, TCP port numbers and in some cases the sequence numbers of
established connections and spoofing packets towards a FreeBSD machine, but
this is harder to do effectively.
IV. Workaround
The mbuf leak can be mitigated by not rate limiting the sending of challenge
ACKs. This can be achieved with immediate effect by setting the
net.inet.tcp.ack_war_timewindow sysctl to 0:
sysctl net.inet.tcp.ack_war_timewindow=0
This mitigation does trade off the leaking of mbufs against additional
CPU/resource cost associated with responding to all challenge ACK eligible
packets received for established TCP connections.
To make this change persistent across reboots, add it to /etc/sysctl.conf.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or release /
security branch (releng) dated after the correction date and reboot.
Perform one of the following:
1) To update your vulnerable system installed from base system packages:
Systems running a 15.0-RELEASE version of FreeBSD on the amd64 or arm64
platforms, which were installed using base system packages, can be updated
via the pkg(8) utility:
# pkg upgrade -r FreeBSD-base
# shutdown -r +10min "Rebooting for a security update"
2) To update your vulnerable system installed from binary distribution sets:
Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms,
which were not installed using base system packages, can be updated via the
freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "Rebooting for a security update"
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-26:06/tcp.patch
# fetch https://security.FreeBSD.org/patches/SA-26:06/tcp.patch.asc
# gpg --verify tcp.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
and reboot the
system.
VI. Correction details
This issue is corrected as of the corresponding Git commit hash in the
following stable and release branches:
Branch/path Hash Revision
- -------------------------------------------------------------------------
stable/15/ 1fddb5435315 stable/15-n282699
releng/15.0/ de9e5d82581e releng/15.0-n281011
stable/14/ b45e7530ffb9 stable/14-n273839
releng/14.4/ 44dd8b58394b releng/14.4-n273676
releng/14.3/ a9cba5321021 releng/14.3-n271476
- -------------------------------------------------------------------------
Run the following command to see which files were modified by a
particular commit:
# git show --stat
Or visit the following URL, replacing NNNNNN with the hash:
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmnEkVIACgkQbljekB8A
Gu/sWRAAtGouQg2M2RuF4+EFK1fpDKyDgBpbx88kH/y2ToHQ/voEwpeC3OOulfQ0
kM7vluUY2yf/yITXJnX/czqxX4flpC9fsAIZtSjXwI27V+xrvWwz/LTgmBumJjgC
VI0i66c6ajie8JC6h4Q2yYpF7M2ymYo/rLXXFM+nq/UpOWLEXbEzzDv6hwvwYqJd
h7pvoNUDWRjbxHykilUQ+KrnEDRz4cdmulil+1aAS1af2WHdROHfOSsVmSY/hQJh
MPA9dJxESzHAjYhjQrLFoWiuSt1JFOt5k/Y6FI4ix1UElJVEvwF7NEj6VxTW9/UX
0sWGmKt23ckfBG6fwBjW2e9NVnqIU4NNMbR0vJghtVsi0K4uw4b5/9n2WbfYYHQZ
eoZ8BiFRdrbRwFgk7NK9UG5r1B0l7O9rJWob0ZUt2/tGYpC7sLz9kOWAptD7JPpE
XkrK354K0KIBPdoVj7QDsK7njYkvnjxlHwWX148gQ1maEX/zWHD6x5RXS+QShzjL
kmp/h5Eiz977qHzotXkK7Le/4EnHQlLYO7n8NafoRrCRszPPlLv1/gaEHYYlTU+S
GMJpvsV9ENd15BhcZRCoLRxwa94D9beDhw89RTgPZ8ItpRO7z1cCfZrNC4aE0x3P
Q+BVMF18lrU/UB4jDW2/BmoGdZSjJMqxHaDGiHZZewQX/dVP2BU=
=a5LJ
-----END PGP SIGNATURE-----