CVE-2024-35910

tcp: properly terminate timers for kernel sockets

MEDIUM
5.8
CVSS Score
Published: May 19, 2024 at 08:35 AM UTC
Updated: October 15, 2026 at 01:17 AM UTC
6 products affected across 3 vendorsLinux KernelDebian LinuxSIMATIC S7-1500 CPU 1518-4 Pn /dp MFP Firmware

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.8
Exploit prediction
EPSS 0.3%
SSVC
No known exploit

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.2 ≤ v < 4.19.3124.20 ≤ v < 5.4.2745.11 ≤ v < 5.15.1545.16 ≤ v < 6.1.855.5 ≤ v < 5.10.2156.2 ≤ v < 6.6.266.7 ≤ v < 6.8.526abe14379f8e2fa3fd1bcf97c9a7ad9364886fe6.96.9 rc1
Vendor states this is fixed in 151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada (fixed)
Vendor states this is fixed in 2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4 (fixed)
Vendor states this is fixed in 44e62f5d35678686734afd47c6a421ad30772e7f (fixed)
Vendor states this is fixed in 899265c1389fe022802aae73dbf13ee08837a35a (fixed)
Vendor states this is fixed in 91b243de910a9ac8476d40238ab3dbfeedd5b7de (fixed)
Vendor states this is fixed in 93f0133b9d589cc6e865f254ad9be3e9d8133f50 (fixed)
Vendor states this is fixed in c1ae4d1e76eacddaacb958b67cd942082f800c87 (fixed)
Vendor states this is fixed in e3e27d2b446deb1f643758a0c4731f5c22492810 (fixed)
Vendor states this is fixed in 4.19.312 (unaffected)
Vendor states this is fixed in 4.2 (unaffected)
Vendor states this is fixed in 5.10.215 (unaffected)
Vendor states this is fixed in 5.15.154 (unaffected)
Vendor states this is fixed in 5.4.274 (unaffected)
Vendor states this is fixed in 6.1.85 (unaffected)
Vendor states this is fixed in 6.6.26 (unaffected)
Vendor states this is fixed in 6.8.5 (unaffected)
Vendor states this is fixed in 6.9 (unaffected)
V3.1.0 ≤ v < V3.1.53.1.0
Affected range stops below V3.1.5, so it looks safe — our inference, not a vendor statement
V3.1.0 ≤ v < V3.1.53.1.0
Affected range stops below V3.1.5, so it looks safe — our inference, not a vendor statement
V3.1.0 ≤ v < V3.1.53.1.0
Affected range stops below V3.1.5, so it looks safe — our inference, not a vendor statement

References (12)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08837a35a
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

5.8MEDIUMCISA-ADP
Attack Vector
LOCAL
Complexity
HIGH
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
LOW
Integrity
LOW
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card