CVE-2024-41006

netrom: Fix a memory leak in nr_heartbeat_expiry()

MEDIUM
5.5
CVSS Score
Published: July 12, 2024 at 12:44 PM UTC
Updated: October 15, 2026 at 01:18 AM UTC
7 products affected across 2 vendorsLinux KernelSIMATIC S7-1500 TM MFPRUGGEDCOM RST2428P 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.5
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: netrom: Fix a memory leak in nr_heartbeat_expiry() syzbot reported a memory leak in nr_create() [0]. Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag. But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b." nr_connect nr_establish_data_link nr_start_heartbeat nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket() To fix the memory leak, let's call sock_hold() only for a listening socket. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

Affected

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

4.19.272 ≤ v < 4.19.3175.10.166 ≤ v < 5.10.2215.15.91 ≤ v < 5.15.1625.4.231 ≤ v < 5.4.2796.1.9 ≤ v < 6.1.966.2 ≤ v < 6.6.366.7 ≤ v < 6.9.74.14.3054.19.272409db27e3a2eb5e8ef7226ca33be33361b3ed1c95.10.1665.15.915.4.23151e394c6f81adbfe7c34d15f58b3d4d44f144acf6.1.96.106.10 rc16.10 rc26.10 rc36.10 rc47de16d75b20ab13b75a7291f449a1b00090edfeaa31caf5779ace8fa98b0d454133808e082ee7a1bd2d3ab1b1de3302de2c85769121fd4f890e47cebe666990abb2e42dd4ba979b4706280a3664cfae7fe9b9e621cebe6b7e83f7e954c70f8bb430520e5
Vendor states this is fixed in 0b9130247f3b6a1122478471ff0e014ea96bb735 (fixed)
Vendor states this is fixed in 280cf1173726a7059b628c610c71050d5c0b6937 (fixed)
Vendor states this is fixed in 5391f9db2cab5ef1cb411be1ab7dbec728078fba (fixed)
Vendor states this is fixed in a02fd5d775cf9787ee7698c797e20f2fa13d2e2b (fixed)
Vendor states this is fixed in b6ebe4fed73eedeb73f4540f8edc4871945474c8 (fixed)
Vendor states this is fixed in d377f5a28332954b19e373d36823e59830ab1712 (fixed)
Vendor states this is fixed in d616876256b38ecf9a1a1c7d674192c5346bc69c (fixed)
Vendor states this is fixed in e07a9c2a850cdebf625e7a1b8171bd23a8554313 (fixed)
Affected range stops below 4.15, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 4.19.317 (unaffected)
Vendor states this is fixed in 5.10.221 (unaffected)
Vendor states this is fixed in 5.15.162 (unaffected)
Vendor states this is fixed in 5.4.279 (unaffected)
Vendor states this is fixed in 6.1.96 (unaffected)
Vendor states this is fixed in 6.10 (unaffected)
Vendor states this is fixed in 6.2 (unaffected)
Vendor states this is fixed in 6.6.36 (unaffected)
Vendor states this is fixed in 6.9.7 (unaffected)
v < V3.1
Affected range stops below V3.1, so it looks safe — our inference, not a vendor statement
v < V3.1
Affected range stops below V3.1, so it looks safe — our inference, not a vendor statement
v < V3.1
Affected range stops below V3.1, so it looks safe — our inference, not a vendor statement
v < V3.1
Affected range stops below V3.1, so it looks safe — our inference, not a vendor statement
v < V3.1
Affected range stops below V3.1, so it looks safe — our inference, not a vendor statement

References (12)

Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/0b9130247f3b6a1122478471ff0e014ea96bb735
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/280cf1173726a7059b628c610c71050d5c0b6937
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/5391f9db2cab5ef1cb411be1ab7dbec728078fba
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/a02fd5d775cf9787ee7698c797e20f2fa13d2e2b
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/b6ebe4fed73eedeb73f4540f8edc4871945474c8
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/d377f5a28332954b19e373d36823e59830ab1712
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c5346bc69c
Mailing ListPatch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/e07a9c2a850cdebf625e7a1b8171bd23a8554313

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

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

CVSS

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

Quick Info

StatusMODIFIED
CWE
CWE-401

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