CVE-2026-64024

What it actually does

The flaw is in the Linux kernel TCP receive path. A TIME_WAIT-derived initial sequence number (ISN) is stored in a per-CPU variable and can remain stale if a packet is dropped before the value is consumed. The next SYN handled on the same CPU can incorrectly reuse that stale value, making the TCP ISN more predictable than intended. Predictable TCP sequence numbers can weaken TCP session integrity protections and may enable off-path or adjacent attackers to spoof, inject, desynchronize, or disrupt TCP connections under favorable network conditions.

Why it matters to the business

Systems running affected Linux kernels may have weakened TCP connection integrity, which can create risk of service disruption, traffic manipulation, or unauthorized interaction with TCP-based services. Internet-facing servers, high-throughput network appliances, load balancers, proxies, and systems using long-lived or sensitive TCP sessions are higher priority because the flaw is remotely reachable and requires no authentication. Although there is no known public exploitation or CISA KEV listing at this time, the high severity and network-level nature of the issue justify prompt kernel updates during the next emergency or accelerated maintenance window.

How an attack unfolds

An attacker sends crafted TCP traffic that reaches a vulnerable Linux host and triggers one of the TCP receive-path drop conditions after the kernel has written a TIME_WAIT-derived ISN into the per-CPU tcp_tw_isn variable. Examples include packets that fail minimum TTL or hop-count checks, XFRM policy checks, TCP MD5/AO validation, attached socket/eBPF filters, checksum validation, SYN+FIN handling, or TCP cookie handling. Because the packet is dropped before tcp_conn_request() consumes the value, the stale ISN remains on that CPU. The attacker then causes or waits for a subsequent SYN to be processed on the same CPU, where the stale non-zero ISN can be consumed for the new connection. If the attacker can predict or influence this sequence, they may be able to improve the feasibility of TCP spoofing, injection, reset, or connection disruption attacks against services on the affected host.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix moving tcp_tw_isn back into the packet control block instead of retaining it in a per-CPU variable. Because no per-distribution fixed versions were provided, obtain the patched kernel from the applicable Linux distribution, vendor advisory, or upstream stable kernel branch. Prioritize exposed servers, network security devices, routers, load balancers, container hosts, and systems terminating untrusted TCP connections. Where immediate patching is not possible, reduce exposure by limiting inbound TCP access to trusted networks, enforcing stateful firewall rules, disabling unnecessary listening services, and using authenticated/encrypted application protocols such as TLS or SSH to reduce the impact of lower-layer TCP spoofing. Mitigations should be treated as risk reduction only; the durable fix is a patched kernel and reboot into that kernel.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix for this issue, not merely that an updated package is installed. On Linux systems, compare `uname -r` with the vendor-fixed kernel version and verify package metadata using the platform package manager. After patching, reboot if required and confirm the active kernel is the updated one. Vulnerability scanners should check the running kernel version and distribution backport status. Because this is a kernel TCP behavior issue, application-level tests are unlikely to conclusively prove remediation; authoritative validation should come from vendor advisory mapping, kernel changelog confirmation, or source verification showing tcp_tw_isn is stored in skb control block state rather than a persistent per-CPU variable.

Typical attack path

1. Identify a reachable Linux system running an affected kernel TCP stack.
2. Send TCP packets designed to enter a path that computes or stores a TIME_WAIT-derived ISN and then drops the packet before normal SYN processing completes.
3. Use repeated attempts, timing, CPU affinity effects, or traffic volume to increase the chance that the next relevant SYN is processed on the same CPU.
4. Observe or infer TCP behavior to narrow the ISN value used for subsequent connections.
5. Use the predictable ISN condition to attempt TCP spoofing, session desynchronization, data injection, connection reset, or denial-of-service against a TCP service.

How to detect it

There is no reliable single log artifact that proves exploitation because the issue occurs inside the kernel TCP receive path and may only manifest as abnormal network behavior. Review host, firewall, load balancer, IDS/IPS, and packet-capture data for unusual TCP activity near exposed Linux services, especially repeated malformed or policy-failing TCP packets followed by connection resets, failed handshakes, unexpected session drops, or suspected spoofed traffic. Useful sources include NetFlow/IPFIX, firewall deny logs, kernel logs, eBPF/network telemetry, IDS alerts for TCP anomalies, packet captures, reverse proxy connection logs, and service logs showing abrupt disconnects. Look for clusters of traffic involving SYN+FIN packets, invalid checksums, TCP MD5/AO authentication failures, XFRM/IPsec policy failures, minimum TTL or hop-count drops, SYN cookie anomalies, and sudden increases in RST packets. Absence of these indicators does not rule out exploitation, and positive findings should be correlated with packet-level evidence and service impact.

What your security team should do

• Inventory Linux systems that expose TCP services to untrusted networks and prioritize them for kernel update and reboot.
• Track distribution advisories for the exact fixed kernel builds and ensure the running kernel, not only the installed package, is remediated.
• Treat internet-facing infrastructure, edge devices, load balancers, VPN concentrators, container hosts, and high-value service endpoints as highest priority.
• Restrict unnecessary inbound TCP access with network ACLs, security groups, host firewalls, and service-level allowlists until patching is complete.
• Monitor for abnormal TCP reset rates, failed connection spikes, SYN anomalies, checksum errors, policy drops, and unexplained session desynchronization around critical services.
• Ensure sensitive application protocols use cryptographic session protection such as TLS to reduce practical impact from TCP sequence manipulation.
• Plan coordinated reboots for kernel replacement and verify post-reboot kernel versions across fleets.