CVE-2026-74696 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix TFO max_qlen accounting across reuseport migration
A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for.
This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one.
fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds.
Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel contains a critical accounting flaw within the TCP Fast Open implementation that affects systems utilizing SO_REUSEPORT socket migration capabilities. This vulnerability arises from an inconsistency in how pending connection requests are tracked when a listener socket is closed and its resources, including active Fast Open handshakes, are transferred to another surviving listener socket. The core issue lies in the lifecycle management of request sockets during this migration process, specifically regarding the tracking of queue lengths which governs resource limits for incoming connections.
TCP Fast Open allows data to be sent along with the initial SYN packet, requiring specific kernel structures to manage pending handshakes that have not yet completed. Each listener socket maintains a maximum queue length parameter known as max_qlen, designed to prevent denial-of-service conditions by limiting the number of pending requests. Under normal operation without reuseport migration, this accounting is handled correctly: when a child connection request is created via tcp_fastopen_create_child(), the global and per-socket queue lengths are incremented. Upon completion or removal of the handshake through reqsk_fastopen_remove(), these counters are decremented based on the listener socket associated with that specific request.
The vulnerability manifests specifically during SO_REUSEPORT migration, a feature allowing multiple sockets to bind to the same address and port for load balancing purposes. When one listener is closed while others remain active, the kernel migrates pending requests from the closing socket to a surviving one. During this transition, inet_reqsk_clone() updates the internal pointers of the request structures so they point toward the new owner socket rather than the original one. However, the code responsible for adjusting queue length counters fails to account for this pointer redirection in the context of Fast Open specific accounting.
The technical flaw occurs because the increment operation performed during child creation is tied to the original listener's data structures, while the subsequent decrement operation upon handshake completion follows the rsk_listener pointer which now points to the new listener socket due to the migration logic. This mismatch results in a situation where the queue length counter for the surviving listener becomes incorrectly decremented without a corresponding prior increment within its own accounting scope. Consequently, this internal qlen value drifts into negative territory rather than remaining at zero or positive values representing actual pending load.
This arithmetic error has significant operational impacts on system stability and security posture. Because the max_qlen limit check relies on comparing current queue lengths against a configured maximum threshold, a negatively drifted counter effectively bypasses this restriction entirely. The kernel perceives that there is ample capacity for new connections when in fact the accounting state is corrupted. This allows far more pending Fast Open requests to be accepted than intended by system administrators or default configurations. Such uncontrolled growth of pending connection states can lead to resource exhaustion, memory pressure, and potential denial-of-service conditions as the kernel allocates resources for an unchecked volume of half-open connections that may never complete their handshakes properly.
From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write in terms of its underlying mechanism of incorrect state manipulation leading to invalid memory or logic states, though more accurately it falls under CWE-691 Insufficient Control Flow Management which leads to improper resource accounting. In the context of attack techniques, this flaw could be leveraged by an attacker performing a TCP Fast Open based denial-of-service attack, mapping to MITRE ATT&CK technique T1498 Network Denial of Service if exploited intentionally to exhaust kernel memory or connection tables through rapid creation and abandonment of fast open handshakes.
The resolution involves correcting the accounting logic during the migration phase by ensuring that queue length adjustments are applied consistently across both the source and destination listener sockets. Specifically, the fix charges the new listener socket with the pending request count at the time of migration, mirroring how other queue metrics like young connections and general qlen are handled in reqsk_queue_migrated(). This ensures that the surviving listener accurately reflects its load immediately upon receiving migrated requests, preventing the counter from drifting negative.
To mitigate this vulnerability, system administrators should ensure that their Linux kernels are updated to include patches addressing tcp_fastopen accounting errors related to reuseport migration. Since this issue affects core networking stack behavior, it is critical for servers relying on high-performance TCP Fast Open implementations and SO_REUSEPORT configurations to apply the relevant kernel updates promptly. Monitoring tools tracking pending connection states may also help identify anomalies indicative of such accounting failures before they lead to resource exhaustion events.