CVE-2024-53124: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().
AI Analysis
Technical Summary
CVE-2024-53124 is a concurrency-related vulnerability in the Linux kernel's networking stack, specifically affecting the handling of TCP and DCCP IPv6 sockets in the net/ipv4/af_inet.c component. The root cause is a data race condition around the sk->sk_forward_alloc field, which is used to track socket memory allocation. The vulnerability arises when two threads concurrently invoke tcp_v6_do_rcv() or dccp_v6_do_rcv() functions on a socket in the TCP_LISTEN state without proper locking, leading to inconsistent and incorrect updates to sk_forward_alloc. This can cause the sk_forward_alloc counter to become negative, violating kernel memory accounting assumptions and potentially leading to memory corruption or use-after-free scenarios. The issue was identified through Syzkaller fuzz testing, which triggered kernel warnings and stack traces indicating improper socket destruction and memory handling. The root cause is that skb_clone_and_charge_r() is called prematurely in tcp_v6_do_rcv() when the socket is still in TCP_LISTEN state, whereas it should only be called later in tcp_v6_syn_recv_sock(). The fix involves correcting this logic and applying the same correction to dccp_v6_do_rcv(). This vulnerability affects Linux kernel versions around 6.12.0-rc5 and likely other recent versions prior to the patch. No known exploits are reported in the wild yet, and no CVSS score has been assigned. However, the vulnerability impacts core kernel networking code and can lead to kernel crashes or memory corruption under concurrent network traffic conditions.
Potential Impact
For European organizations, this vulnerability poses a significant risk to servers and network infrastructure running vulnerable Linux kernel versions, especially those handling high volumes of IPv6 TCP or DCCP traffic. Exploitation could lead to kernel crashes (denial of service), memory corruption, or potentially privilege escalation if an attacker can carefully craft network packets to trigger the race condition. This could disrupt critical services such as web servers, mail servers, and network appliances, impacting availability and integrity of systems. Given the widespread use of Linux in European data centers, cloud providers, and enterprise environments, the vulnerability could affect a broad range of sectors including finance, telecommunications, government, and critical infrastructure. The absence of authentication or user interaction requirements means that remote attackers could potentially exploit this vulnerability by sending specially crafted network traffic to vulnerable hosts, increasing the attack surface. Although no active exploits are known, the complexity of the bug and its presence in fundamental kernel networking code make it a high-risk issue that demands prompt attention.
Mitigation Recommendations
European organizations should immediately assess their Linux kernel versions and apply the official patches or upgrade to a fixed kernel release that addresses CVE-2024-53124. Since the vulnerability involves kernel memory management and concurrency, relying on backported patches from trusted Linux distributions (e.g., Debian, Ubuntu, Red Hat, SUSE) is critical. Network administrators should consider implementing IPv6 traffic filtering or rate limiting on exposed interfaces to reduce the risk of exploitation until patches are applied. Monitoring kernel logs for warnings related to inet_sock_destruct or sk_forward_alloc anomalies can help detect attempted exploitation or instability. For high-security environments, deploying kernel live patching solutions can minimize downtime during remediation. Additionally, organizations should review and harden their network segmentation and firewall rules to limit exposure of vulnerable services to untrusted networks. Finally, maintaining robust incident response plans and backups is essential to recover quickly from potential exploitation or denial-of-service events.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain, Poland, Belgium
CVE-2024-53124: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().
AI-Powered Analysis
Technical Analysis
CVE-2024-53124 is a concurrency-related vulnerability in the Linux kernel's networking stack, specifically affecting the handling of TCP and DCCP IPv6 sockets in the net/ipv4/af_inet.c component. The root cause is a data race condition around the sk->sk_forward_alloc field, which is used to track socket memory allocation. The vulnerability arises when two threads concurrently invoke tcp_v6_do_rcv() or dccp_v6_do_rcv() functions on a socket in the TCP_LISTEN state without proper locking, leading to inconsistent and incorrect updates to sk_forward_alloc. This can cause the sk_forward_alloc counter to become negative, violating kernel memory accounting assumptions and potentially leading to memory corruption or use-after-free scenarios. The issue was identified through Syzkaller fuzz testing, which triggered kernel warnings and stack traces indicating improper socket destruction and memory handling. The root cause is that skb_clone_and_charge_r() is called prematurely in tcp_v6_do_rcv() when the socket is still in TCP_LISTEN state, whereas it should only be called later in tcp_v6_syn_recv_sock(). The fix involves correcting this logic and applying the same correction to dccp_v6_do_rcv(). This vulnerability affects Linux kernel versions around 6.12.0-rc5 and likely other recent versions prior to the patch. No known exploits are reported in the wild yet, and no CVSS score has been assigned. However, the vulnerability impacts core kernel networking code and can lead to kernel crashes or memory corruption under concurrent network traffic conditions.
Potential Impact
For European organizations, this vulnerability poses a significant risk to servers and network infrastructure running vulnerable Linux kernel versions, especially those handling high volumes of IPv6 TCP or DCCP traffic. Exploitation could lead to kernel crashes (denial of service), memory corruption, or potentially privilege escalation if an attacker can carefully craft network packets to trigger the race condition. This could disrupt critical services such as web servers, mail servers, and network appliances, impacting availability and integrity of systems. Given the widespread use of Linux in European data centers, cloud providers, and enterprise environments, the vulnerability could affect a broad range of sectors including finance, telecommunications, government, and critical infrastructure. The absence of authentication or user interaction requirements means that remote attackers could potentially exploit this vulnerability by sending specially crafted network traffic to vulnerable hosts, increasing the attack surface. Although no active exploits are known, the complexity of the bug and its presence in fundamental kernel networking code make it a high-risk issue that demands prompt attention.
Mitigation Recommendations
European organizations should immediately assess their Linux kernel versions and apply the official patches or upgrade to a fixed kernel release that addresses CVE-2024-53124. Since the vulnerability involves kernel memory management and concurrency, relying on backported patches from trusted Linux distributions (e.g., Debian, Ubuntu, Red Hat, SUSE) is critical. Network administrators should consider implementing IPv6 traffic filtering or rate limiting on exposed interfaces to reduce the risk of exploitation until patches are applied. Monitoring kernel logs for warnings related to inet_sock_destruct or sk_forward_alloc anomalies can help detect attempted exploitation or instability. For high-security environments, deploying kernel live patching solutions can minimize downtime during remediation. Additionally, organizations should review and harden their network segmentation and firewall rules to limit exposure of vulnerable services to untrusted networks. Finally, maintaining robust incident response plans and backups is essential to recover quickly from potential exploitation or denial-of-service events.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-11-19T17:17:24.995Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9824c4522896dcbdfa86
Added to database: 5/21/2025, 9:08:52 AM
Last enriched: 6/28/2025, 3:11:55 PM
Last updated: 7/31/2025, 3:10:33 PM
Views: 11
Related Threats
Researcher to release exploit for full auth bypass on FortiWeb
HighCVE-2025-9091: Hard-coded Credentials in Tenda AC20
LowCVE-2025-9090: Command Injection in Tenda AC20
MediumCVE-2025-9092: CWE-400 Uncontrolled Resource Consumption in Legion of the Bouncy Castle Inc. Bouncy Castle for Java - BC-FJA 2.1.0
LowCVE-2025-9089: Stack-based Buffer Overflow in Tenda AC20
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.