CVE-2024-41007: tcp: avoid too many retransmit packets
In the Linux kernel, the following vulnerability has been resolved:
tcp: avoid too many retransmit packets
If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
retracted its window to zero, tcp_retransmit_timer() can
retransmit a packet every two jiffies (2 ms for HZ=1000),
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
The fix is to make sure tcp_rtx_probe0_timed_out() takes
icsk->icsk_user_timeout into account.
Before blamed commit, the socket would not timeout after
icsk->icsk_user_timeout, but would use standard exponential
backoff for the retransmits.
Also worth noting that before commit e89688e3e978 ("net: tcp:
fix unexcepted socket die when snd_wnd is 0"), the issue
would last 2 minutes instead of 4.
Security readout for executives and security teams
Plain-English summary
A Linux TCP flaw can cause a system to transmit packets excessively after an application-defined connection timeout has expired. A remote peer that reduces its receive window to zero can trigger the condition, potentially consuming network and processing resources and disrupting availability. The supplied severity is CVSS 7.5 High.
Executive priority
Treat this as a high-priority availability issue, especially for exposed, connection-heavy Linux services. Patch through normal expedited kernel maintenance after confirming vendor applicability. Emergency isolation is not justified by the supplied evidence alone because active exploitation is unconfirmed and exposure depends on TCP_USER_TIMEOUT usage.
Technical view
When TCP_USER_TIMEOUT is configured and the peer advertises a zero window, tcp_retransmit_timer() may retransmit approximately every two jiffies for about four minutes beyond the timeout. The correction makes tcp_rtx_probe0_timed_out() account for icsk_user_timeout. The reported impact is availability loss; confidentiality and integrity impacts are not identified.
Likely exposure
Exposure is limited to affected Linux kernels and TCP sockets configured with TCP_USER_TIMEOUT. Practical risk is greater where untrusted remote peers can maintain TCP connections and advertise a zero receive window. The supplied affected-version data includes several kernel lines, but precise distribution-specific package boundaries require vendor confirmation.
Exploitation context
The issue is remotely triggerable with low stated complexity and requires neither privileges nor user interaction according to the supplied CVSS vector. However, it is not in KEV, and the provided sources contain no evidence of active exploitation. Public proof-of-concept availability is not established by this bundle.
Researcher notes
The vulnerable behavior is a rapid probe retransmission loop continuing beyond the configured user timeout when the peer's send window is zero. Upstream supplied separate stable-tree corrections. The bundle does not establish resource-consumption measurements, confirmed denial-of-service cases, exploit availability, or exact package-level boundaries for every distribution.
Mitigation direction
Install a vendor-supported kernel update containing the applicable upstream stable fix.
Consult the Linux distribution advisory to identify the corrected package for each deployed kernel.
Prioritize externally reachable systems that use TCP_USER_TIMEOUT with untrusted peers.
Apply normal network resource monitoring while updates are being scheduled.
Validation and detection
Inventory running kernel and distribution package versions across Linux systems.
Compare each package against current distribution advisories and applicable stable fix commits.
Identify applications or services that configure TCP_USER_TIMEOUT.
After updating, verify the running kernel changed and the vendor marks the CVE resolved.
Monitor for abnormal TCP retransmission volume and sustained zero-window connections.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-41007 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.