CVE-2024-41006: In the Linux kernel, the following vulnerability has been resolved: netrom: Fix a memory leak in nr_heartbeat_expiry() syzbot reported a memory leak...

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

Metrics

CVSS 3.1

5.5/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS Probability

0.24%

15.3th percentile

Probability of exploitation in the next 30 days. Learn more

Weakness Enumeration

CWE-401

Affected Software

Vendor	Product	Versions	Update
Linux	Linux Kernel	>= 4.19.272, < 4.19.317	—
Linux	Linux Kernel	>= 5.4.231, < 5.4.279	—
Linux	Linux Kernel	>= 5.10.166, < 5.10.221	—
Linux	Linux Kernel	>= 5.15.91, < 5.15.162	—
Linux	Linux Kernel	>= 6.1.9, < 6.1.96	—
Linux	Linux Kernel	>= 6.2, < 6.6.36	—
Linux	Linux Kernel	>= 6.7, < 6.9.7	—
Linux	Linux Kernel	6.10	Rc1

References

https://git.kernel.org/stable/c/0b9130247f3b6a1122478471ff0e014ea96bb735Mailing List, Patch
https://git.kernel.org/stable/c/280cf1173726a7059b628c610c71050d5c0b6937Mailing List, Patch
https://git.kernel.org/stable/c/5391f9db2cab5ef1cb411be1ab7dbec728078fbaMailing List, Patch
https://git.kernel.org/stable/c/a02fd5d775cf9787ee7698c797e20f2fa13d2e2bMailing List, Patch
https://git.kernel.org/stable/c/b6ebe4fed73eedeb73f4540f8edc4871945474c8Mailing List, Patch
https://git.kernel.org/stable/c/d377f5a28332954b19e373d36823e59830ab1712Mailing List, Patch
https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c5346bc69cMailing List, Patch
https://git.kernel.org/stable/c/e07a9c2a850cdebf625e7a1b8171bd23a8554313Mailing List, Patch
https://git.kernel.org/stable/c/0b9130247f3b6a1122478471ff0e014ea96bb735Mailing List, Patch
https://git.kernel.org/stable/c/280cf1173726a7059b628c610c71050d5c0b6937Mailing List, Patch
https://git.kernel.org/stable/c/5391f9db2cab5ef1cb411be1ab7dbec728078fbaMailing List, Patch
https://git.kernel.org/stable/c/a02fd5d775cf9787ee7698c797e20f2fa13d2e2bMailing List, Patch
https://git.kernel.org/stable/c/b6ebe4fed73eedeb73f4540f8edc4871945474c8Mailing List, Patch
https://git.kernel.org/stable/c/d377f5a28332954b19e373d36823e59830ab1712Mailing List, Patch
https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c5346bc69cMailing List, Patch
https://git.kernel.org/stable/c/e07a9c2a850cdebf625e7a1b8171bd23a8554313Mailing List, Patch
https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
https://cert-portal.siemens.com/productcert/html/ssa-265688.html
https://cert-portal.siemens.com/productcert/html/ssa-355557.html
https://cert-portal.siemens.com/productcert/html/ssa-613116.html

Timeline

Published: Jul 12, 2024
Last Modified: Jun 17, 2026
Status: Modified

Frequently Asked Questions

What is CVE-2024-41006?

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

How severe is CVE-2024-41006?

CVE-2024-41006 has a CVSS score of 5.5/10 (MEDIUM severity). The EPSS model estimates a 0.24% probability of exploitation in the next 30 days.

How do I fix CVE-2024-41006?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.