TCP: remotely exploitable DoS vector (mbuf leak)
FreeBSD-SA-26:06.tcp · CVE-2026-4247
Our decision for FreeSense
FreeBSD corrected this on 2026-03-26, before the FreeBSD source pin of every FreeSense version.
- Advisory: corrected 2026-03-26
- FreeSense 1.0 pin: e004ff15f87e (2026-08-03)
- FreeSense 1.1 pin: a52c50b4b7c2 (2026-10-04)
- FreeSense 1.2 pin: a52c50b4b7c2 (2026-10-04)
By FreeSense version
| Version | Status | FreeBSD pin |
|---|---|---|
| FreeSense 1.01.0.7 · frozen, no further fixes | FixedFreeBSD pin of 2026-08-03 | 2026-08-03e004ff15 |
| FreeSense 1.11.1.9 | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
| FreeSense 1.21.2.0-DEVELOPMENT | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
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.
What FreeBSD says
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.
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 e
Excerpt from the FreeBSD advisory. Read the original for the full text and the fix.