FreeBSD CVE-2026-101307: A Flood of ACKs Writes 512 KB Out of Bounds in the Kernel Through the TCP RACK Stack

Published by NVD on October 15, 2026 and since analyzed, CVE-2026-101307 affects the TCP RACK stack in FreeBSD 15.1. A remote peer with an established TCP connection can send enough ACKs to trigger an out-of-bounds write of roughly 512 KB in the kernel heap.

No authentication, no user interaction: an established TCP connection is all it takes. That's what makes this one worth a look for anyone exposing a service on a FreeBSD box that uses RACK.

The Vulnerability

The CVE isn't in CISA KEV at the time of writing.

How It Works

The RACK stack keeps an array of PCM samples. When that array needs to grow, the code doubles an allocation counter stored in 16 bits.

You can only double a 16-bit value so many times: after enough doublings, the counter wraps to zero. The kernel then allocates a near-zero-length buffer and copies the existing samples into it. Hence the out-of-bounds write, about 512 KB according to the description.

And it's the remote peer that drives the array's growth: all it has to do is send enough ACKs on an established connection.

It's a textbook bug class — an integer wraparound turning into a buffer overflow — but sitting in the most exposed code path there is: processing inbound TCP segments.

Two Scores, Two Readings

• NVD rates it 9.1, with high integrity impact (I:H) on top of availability: a 512 KB write into the kernel heap corrupts arbitrary data.
• FreeBSD, as the CNA, only counts availability in its CVSS 4.0 score (VA:H, 8.2) and adds AT:P (a precondition: the RACK stack must be in use).

The description says "possibly resulting in a kernel panic". The documented outcome is therefore the machine going down. Code execution isn't described; it can't be ruled out with a write of that size, but nothing in the published data establishes it.

Who Is Affected

Two conditions:

1. FreeBSD 15.1, up to and including patch level p4 (NVD's CPE configurations);
2. the TCP RACK stack is in use for the connections involved.

FreeBSD supports several loadable TCP stacks, and which one is used comes down to configuration. Check what's active:

sysctl net.inet.tcp.functions_available
sysctl net.inet.tcp.functions_default
kldstat | grep tcp_rack

If rack shows up neither as the default stack nor as one selected by an application, the machine doesn't go down the vulnerable path. FreeBSD-based products (appliances, firewalls, storage) that enable RACK should be checked with their vendor.

The Fix

NVD lists 15.1 through 15.1-p4 as vulnerable but doesn't explicitly name the fixed release. The patch level to install and the source patches are in advisory FreeBSD-SA-26:70.tcp.

On a binary install:

freebsd-update fetch
freebsd-update install
shutdown -r now

The fix is in the kernel: a reboot is mandatory.

Detection and Interim Measures

• Unexplained kernel panics on exposed servers: check /var/crash and the system logs.
• Connections with an abnormal volume of ACKs: a spike of ACK traffic on a single connection, with no matching data, is the signal to look for in packet captures.
• Possible workaround: switch back to FreeBSD's default TCP stack instead of RACK by changing net.inet.tcp.functions_default, then restart services so new connections pick it up. That's an inference to check against the advisory, which is authoritative on workarounds.
• Filtering: restricting access to services that don't need to be public reduces the number of peers able to open a connection.

Why Continuous Monitoring of Your FreeBSD Systems Matters

A TCP stack flaw isn't about some piece of software installed on the side: it hits the kernel of every server, and hinges on a setting that's easy to forget. Knowing which machines run 15.1, and at what patch level, is what lets you act the day the advisory lands.

With cveo.tech, inventory your FreeBSD systems with their versions and get an alert as soon as a critical CVE hits them.