CVE-2026-68118

What it actually does

This is a Linux kernel TCP state-handling flaw in the SYN-RECEIVED path. When a server has received a SYN and sent a SYN-ACK, but the connection is not yet fully established, the vulnerable code accepts an in-window TCP RST segment even when its sequence number does not exactly match the next expected sequence number. Per RFC 9293/RFC 5961 behavior, that non-exact RST should be dropped and answered with a challenge ACK. Instead, the vulnerable kernel removes the pending request socket, allowing an attacker to prematurely tear down connection attempts. The practical impact is denial of service against TCP connection establishment; it does not provide code execution, privilege escalation, or direct data access.

Why it matters to the business

Attackers may be able to disrupt access to services hosted on affected Linux systems by repeatedly aborting new TCP connection attempts before they complete. Internet-facing services, high-volume APIs, load balancers, proxies, VPN gateways, and other systems that rely on stable TCP handshakes may experience intermittent connection failures, degraded availability, increased retries, and customer-visible outages. This issue was published recently, is not currently listed in CISA KEV, and has no reported exploit maturity in the provided data, but Linux kernel flaws can become operationally important once fixes and behavioral differences are analyzed publicly.

How an attack unfolds

An attacker targets a TCP service on a vulnerable Linux host while the server has a request socket in SYN-RECEIVED state. The attacker sends or induces a connection attempt, then transmits a crafted TCP RST segment that falls within the acceptable receive window but does not exactly match the expected sequence number. On a correctly implemented stack, this segment would trigger a challenge ACK and be ignored. On a vulnerable kernel, the request socket is removed, causing the pending handshake to fail. By repeating this process against many connection attempts, an attacker can cause intermittent or sustained denial of service for new connections. An on-path attacker can perform this more reliably because they can observe sequence numbers and timing; an off-path attacker would need to infer or guess the relevant 4-tuple and sequence-window details, making exploitation harder but still relevant for exposed, high-volume services.

How to fix it

Apply Linux kernel updates from the relevant distribution or kernel vendor that include the fix for this TCP SYN-RECEIVED RST validation behavior. No exact fixed package versions were provided in the input, so track vendor advisories for the deployed kernel streams and prioritize externally reachable systems that terminate TCP connections directly. If immediate patching is not possible, reduce exposure where feasible by placing vulnerable systems behind patched load balancers or TCP proxies, limiting direct internet reachability, applying upstream DDoS protections, and monitoring for abnormal TCP reset patterns. General hardening such as SYN cookies and connection-rate limiting may reduce adjacent handshake-exhaustion risks, but they should not be treated as a complete fix for this protocol-state bug.

How to confirm the fix worked

Confirm the running kernel version is a vendor build that includes the upstream TCP challenge-ACK fix for non-exact RST handling in SYN-RECEIVED state. Validate both package inventory and active runtime state, since a patched kernel package is not effective until the system boots into it. In a controlled test environment, reproduce a half-open TCP handshake and inject an in-window but non-exact RST: a vulnerable system will remove the pending request, while a fixed system should drop the RST and send a challenge ACK. Use packet capture to verify the challenge ACK behavior. For production exposure review, identify Linux systems that directly terminate TCP services and verify they are covered by patched kernel versions or protected by patched upstream TCP termination points.

Typical attack path

1. Identify a TCP service hosted on a vulnerable Linux kernel.
2. Create, observe, or predict pending TCP handshakes that leave the server in SYN-RECEIVED state.
3. Craft TCP RST packets for the target 4-tuple with a sequence number inside the receive window but not exactly equal to the expected next sequence number.
4. Send the crafted RST packets before the final ACK of the handshake is processed.
5. Cause the vulnerable kernel to remove the request socket instead of issuing a challenge ACK.
6. Repeat the technique to disrupt new connection establishment and degrade service availability.

How to detect it

This issue is difficult to confirm after the fact because successful exploitation may leave no host-level artifact, process, file, or authentication log entry. The best evidence comes from packet captures, flow logs, firewall logs, load balancer telemetry, and service availability metrics. Look for spikes in TCP RST packets aimed at listening service ports while connection establishment failures, SYN-RECEIVED churn, client retry rates, or handshake timeouts increase. Packet-level analysis should focus on RST packets received during the SYN/SYN-ACK/ACK handshake where the RST sequence number is within the acceptable window but not exactly the next expected sequence number. On-path exploitation may appear as precisely timed RSTs immediately after SYN-ACKs; off-path attempts may appear as high-volume or statistically abnormal RST traffic with spoofed or inconsistent source characteristics. Because there are no named threat actors or known campaigns in the provided data, detection should emphasize behavioral network anomalies rather than actor-specific indicators.

• TCP RST packets received immediately after SYN-ACK and before handshake completion
• Abnormally high TCP RST volume targeting listening service ports
• Repeated TCP handshakes failing while server-side state is SYN-RECEIVED
• tcpdump output containing "Flags [R]" for packets targeting service ports during incomplete TCP handshakes
• Flow-log pattern: SYN followed by SYN-ACK followed by RST with no completed ACK
• Spike in connection reset errors coinciding with increased incomplete TCP handshakes

What your security team should do

• Prioritize patching internet-facing Linux systems that directly terminate TCP connections, especially load balancers, reverse proxies, API endpoints, VPN concentrators, and high-traffic service nodes.
• Confirm systems have rebooted into the patched kernel after updates; do not rely only on installed package versions.
• Monitor vendor advisories for exact fixed versions across deployed Linux distributions and kernel branches.
• Use network telemetry or packet captures to look for abnormal volumes of TCP RST packets during incomplete handshakes, particularly where connection failure rates rise at the same time.
• Review edge protections, rate limits, and DDoS controls for services that could be affected by repeated handshake disruption.
• If patching is delayed, route traffic through patched TCP termination infrastructure or restrict direct access to vulnerable hosts where operationally possible.
• Treat confirmed exploitation primarily as an availability incident, while still preserving packet captures and flow logs for attribution and recurrence analysis.