EUVD-2026-101882
GHSA-gpr4-gr7v-w9p3
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessEstablish TCP connection to RACK stack
-
DeliveryFlood connection with many ACKs
-
ExploitTrigger 16-bit counter wrap to zero
-
ExecutionUndersized buffer copy overflows kernel heap
-
ImpactKernel panic denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Heap buffer bounds checking
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the target to be running the alternate RACK TCP stack, which is NOT the FreeBSD default and must be explicitly enabled (e.g. loading the tcp_rack module and setting net.inet.tcp.functions_default=rack, or selecting it per-socket via TCP_FUNCTION_BLK). Given that, exploitation is remote and unauthenticated (PR:N): the attacker only needs to establish a TCP connection and send a sufficient number of ACKs to drive repeated doublings of the PCM sample array until the 16-bit counter wraps. Limiting factors: the attack requirement (AT:P) reflects that many ACKs must be sent to reach the wrap condition, the RACK stack is non-default so most stock FreeBSD hosts are unaffected, only FreeBSD 15.1-RELEASE before p5 is vulnerable, and impact is restricted to a kernel panic (denial of service) with no confidentiality or integrity impact. |
| Impact | Signals are consistent and point to a moderate, availability-only risk rather than a top-tier emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) describes a remote, unauthenticated attack with an attack requirement (AT:P), and impact is confined to availability (VA:H; VC:N/VI:N) - i.e. a kernel panic / denial of service, not code execution or data disclosure, despite the heap out-of-bounds write (CWE-122). EPSS is very low (0.17%, 6th percentile) and CISA SSVC reports Exploitation: none, Automatable: no, Technical Impact: partial, which aligns with the absence of any KEV listing or public POC. These signals do not conflict: a genuinely reachable remote DoS that nonetheless requires driving a specific counter-overflow condition on a non-default TCP stack. One caveat worth verifying: although the OOB write is in the kernel heap, both the CVSS impact metrics and the description scope the outcome to a kernel panic (DoS) rather than memory corruption leading to code execution - treat any 'RCE' framing as unconfirmed. Net: a real but bounded priority, mainly for FreeBSD hosts that have explicitly enabled the RACK stack; not a drop-everything issue given low EPSS, no KEV, and no public exploit. |
| Exploit ScenarioDerived | A remote, unauthenticated attacker opens a normal TCP connection to a FreeBSD host running the RACK stack and sends a large number of ACKs on the established connection, forcing repeated doublings of the 16-bit PCM-sample allocation counter until it wraps to zero. The subsequent copy of existing samples into the near-zero-length buffer produces an ~512 KB out-of-bounds write in the kernel heap, panicking the system. No public exploit code has been identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 15, 2026
Heap out-of-bounds write in the FreeBSD RACK TCP stack (CVE-2026-101307) lets a remote, unauthenticated attacker who completes a TCP handshake and sends a sufficient number of ACKs cause a 16-bit PCM sample-array growth counter to wrap to zero, producing a near-zero-length kernel heap allocation that is then overwritten with roughly 512 KB of existing sample data. The result is a kernel panic - availability impact only, with no confidentiality or integrity loss - and only FreeBSD 15.1-RELEASE before p5 hosts that have explicitly enabled the non-default RACK stack are exposed; stock FreeBSD hosts using the default stack are unaffected. No public exploit code has been identified at time of analysis, CISA SSVC records exploitation as 'none', and EPSS is 0.17% (6th percentile), so the practical near-term risk is moderate and conditional on RACK being enabled.
Earlier versions of this analysis (1)
A heap out-of-bounds write in the FreeBSD RACK TCP stack lets a remote peer crash the kernel by sending a sufficiently large number of ACKs on an established connection, which drives repeated doublings of a 16-bit PCM sample-array counter until it wraps to zero, leaving a near-zero-length allocation that the kernel then fills with roughly 512 KB of existing sample data. Only systems running FreeBSD 15.1-RELEASE prior to patch level p5 with RACK explicitly enabled are affected; RACK is not the default TCP stack, and that configuration requirement is the primary limiting factor on real-world exposure. Impact is confined to a kernel panic and resulting denial of service, with no confidentiality or integrity compromise claimed, and while the flaw is remotely reachable without authentication per our assessed vector, no public exploit code has been identified at time of analysis and the EPSS score is low at 0.17% (6th percentile).
RemediationAI
Apply the vendor fix documented in FreeBSD Security Advisory FreeBSD-SA-26:70.tcp (https://security.freebsd.org/advisories/FreeBSD-SA-26:70.tcp.asc); the EUVD affected range ends at 15.1-RELEASE-p5, so upgrading to FreeBSD 15.1-RELEASE-p5 or later is the fix. Because RACK is not the default stack, the strongest compensating control for hosts that cannot immediately patch is to simply not use it: do not load the tcp_rack module, and ensure net.inet.tcp.functions_default is left at the default stack rather than set to rack - if tcp_rack is already loaded but unused, it can be removed with kldunload tcp_rack (the unload will fail while any socket still references the stack, which itself confirms RACK is in active use). The trade-off is the loss of RACK's advanced loss-recovery and pacing behavior, which can degrade throughput on lossy or high-BDP paths, so this is a viable short-term measure rather than a permanent substitute for the p5 patch. Any per-socket TCP_FUNCTION_BLK callers that explicitly request RACK should be reconfigured to the default stack as well, since switching the global default alone will not cover them. Network-level mitigations such as restricting which peers may establish TCP connections are weak here because the trigger is a legitimate traffic pattern (ACKs) on an already-established connection, and blocking ports or adding rate limits does not remove the wrapping condition. Prioritize patching on hosts where RACK was deliberately enabled; for everything else, confirming RACK is absent is sufficient to close the exposure.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is a CWE-122 heap-based buffer overflow in FreeBSD's RACK loss-recovery/pacing TCP stack, a non-default alternative stack shipped as the tcp_rack loadable kernel module. Internally, the stack maintains a PCM sample array that expands as samples accumulate; the expansion logic doubles a 16-bit allocation counter. Because doubling a 16-bit value wraps at 65,536, repeatedly triggered expansions drive the counter to zero, so the next reallocation computes a near-zero size while the code still copies the previously stored samples into that undersized buffer - an out-of-bounds write of approximately 512 KB into the kernel heap. A remote peer on an established connection can force those repeated expansions simply by sending enough ACKs, which is why the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H: remote and unauthenticated (PR:N), but with high attack complexity (AC:H) reflecting the volume of ACKs needed and the Attack Requirements (AT:P) sub-score in the vendor CVSS 4.0 vector. Impact is confined to a kernel panic; there is no data disclosure or modification. No CPE strings were supplied with the intelligence feed, but ENISA EUVD pins the affected build to FreeBSD 15.1-RELEASE before p5, and the FreeBSD Security Team (secteam@freebsd.org) is the reporting party.
Know when Freebsd gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Remote and unauthenticated (AV:N/PR:N); AC:H reflects the need to send enough ACKs to force the counter wrap; only a kernel-panic DoS, so C:N/I:N/A:H, scope unchanged.
Primary rating from Vendor (freebsd).
CVSS VectorVendor: freebsd
Lifecycle Timeline
4DescriptionCVE.org
When the PCM sample array needs to grow, the RACK stack doubles a 16-bit allocation counter. Repeated doublings caused the counter to wrap to zero, resulting in a near-zero-length allocation followed by a copy of the existing samples into the undersized buffer. A remote peer can trigger the expansion by sending a sufficient number of ACKs on an established connection.
A remote attacker who can establish a TCP connection to a system using the RACK stack can trigger an out-of-bounds write of approximately 512 KB in the kernel heap possibly resulting in a kernel panic.
Executive ViewAI
FreeBSD 15.1-RELEASE hosts that have enabled the optional RACK TCP stack are susceptible to a remote denial-of-service vulnerability that can cause kernel panics, resulting in unplanned downtime. While the default stack is not affected and no public exploit identified at time of analysis, organizations relying on RACK for performance or specific workloads must act to prevent service disruptions. Leadership should prioritize identifying affected systems and implementing interim mitigations until a vendor patch is released.
No vendor-released patch identified at time of analysis. Disable the RACK TCP stack (sysctl net.inet.tcp.rack.enable=0) or ensure hosts use the default stack. If RACK cannot be disabled, restrict network access to affected hosts to trusted IP ranges and monitor for kernel panics.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
A heap overflow occurs when a program writes data beyond the bounds of a buffer allocated in the heap memory region.
The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and
The rtsol(8) and rtsold(8) programs do not validate the domain search list options provided in router advertisement mess
Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due
The RFC 5011 implementation in rdata.c in ISC BIND 9.7.x and 9.8.x before 9.8.5-P2, 9.8.6b1, 9.9.x before 9.9.3-P2, and
Remote code execution in OpenSSH's sshd server (regression of CVE-2006-5051) allows unauthenticated remote attackers to
An issue was discovered in OpenSSH 7.9. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no
The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remot
The vm_map_lookup function in sys/vm/vm_map.c in the mmap implementation in the kernel in FreeBSD 9.0 through 9.1-RELEAS
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. Rated med
Integer overflow in the _gd2GetHeader function in gd_gd2.c in the GD Graphics Library (aka libgd) before 2.2.3, as used
The Stream Control Transmission Protocol (SCTP) module in FreeBSD 9.3 before p33, 10.1 before p26, and 10.2 before p9, w
In FreeBSD 12.1-STABLE before r359565, 12.1-RELEASE before p7, 11.4-STABLE before r362975, 11.4-RELEASE before p1, and 1
Exploit-DB