CVE-2024-35910: tcp: properly terminate timers for kernel sockets
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after
the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often,
and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context,
including when socket lock is held.
This is the reason it uses sk_stop_timer(), aka del_timer().
This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer
holds a reference on the socket, and the user socket holds
a reference on the netns.
For kernel sockets, we risk that the netns is freed before
timer can complete, because kernel sockets do not hold
reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function
that using sk_stop_timer_sync() to make sure all timers
are terminated before the kernel socket is released.
Modules using kernel sockets close them in their netns exit()
handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP
support : inet_csk_clear_xmit_timers_sync() must not be called
while socket lock is held.
It is very possible we can revert in the future commit
3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
which attempted to solve the issue in rds only.
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from
tcp_out_of_resources() and __tcp_close() in the future.
Security readout for executives and security teams
Plain-English summary
A Linux TCP cleanup race can leave a timer running after its network namespace has been dismantled. A later timer callback could access already-freed namespace state, potentially compromising the host. The supplied CVSS rates possible confidentiality, integrity, and availability impacts as high, but the evidence does not establish active exploitation or a reliable attack technique.
Executive priority
Treat this as an urgent kernel-maintenance issue rather than a confirmed incident. Accelerate remediation on multi-tenant, container-heavy, and locally accessible hosts. Normal patch prioritization may be appropriate for tightly controlled systems, but validate exact vendor exposure because the supplied version representation is incomplete.
Technical view
TCP socket closure used asynchronous timer deletion, which may return while a callback is still executing. User sockets retain a network-namespace reference, but kernel sockets do not. During namespace teardown, this creates a lifetime race. The upstream fix synchronously terminates kernel-socket timers before release and adds a lock-ownership check for safe use.
Likely exposure
Systems running affected Linux kernel builds are candidates, especially when modules use kernel TCP sockets and network namespaces are frequently destroyed. The supplied CVSS requires local, low-privileged access; network access alone is insufficient. Because the bundled version data is ambiguous, determine exposure through distribution advisories, installed package versions, and referenced stable fixes.
Exploitation context
CISA KEV status is false, and the supplied sources do not report active exploitation. The issue was observed through syzbot reports and reproducible kernel testing. Exploitation feasibility, reliability, and required module or namespace conditions are not established by this source bundle.
Researcher notes
The critical invariant is that TCP timers for kernel sockets must finish before their socket and network namespace are released. Synchronous cancellation cannot occur while holding the socket lock. The supplied evidence does not identify a CWE, reliable exploitation primitive, public proof of concept, or all module-specific preconditions.
Mitigation direction
Install a distribution-supported kernel containing the applicable upstream stable fix.
Reboot after updating, then confirm the corrected kernel is actively running.
If immediate patching is unavailable, obtain product-specific compensating guidance from the Linux or appliance vendor.
Prioritize multi-tenant systems and hosts permitting untrusted users to execute local code.
Validation and detection
Inventory running kernel and distribution package versions across Linux systems.
Compare each package against distribution advisories and the referenced stable fix for its kernel branch.
Identify workloads or modules using kernel TCP sockets alongside network-namespace teardown.
Confirm updated systems were rebooted and are running the intended fixed kernel.
Review kernel crash and namespace-related logs for anomalies, while recognizing these cannot prove exploitation.
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-35910 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.