CVE-2024-44935 in Linux
Summary
by MITRE • 08/26/2024
In the Linux kernel, the following vulnerability has been resolved:
sctp: Fix null-ptr-deref in reuseport_add_sock().
syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0]
The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener.
The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock().
The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock().
The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must
provide synchronisation for sockets that are classified into the same reuseport group.
Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead.
1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[]
3. Two sockets call reuseport_alloc() and form two reuseport groups 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packets
Also, the reported null-ptr-deref could occur.
TCP/UDP guarantees that would not happen by holding the hash bucket lock.
Let's apply the locking strategy to __sctp_hash_endpoint() and __sctp_unhash_endpoint().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __sctp_hash_endpoint net/sctp/input.c:762 [inline]
sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline]
sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline]
__sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]
__se_sys_listen net/socket.c:1900 [inline]
__x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2024
The vulnerability described in CVE-2024-44935 affects the Linux kernel's Stream Control Transmission Protocol implementation, specifically within the reuseport functionality. This issue manifests as a null pointer dereference during the execution of reuseport_add_sock() function, which occurs when handling concurrent socket operations involving SO_REUSEPORT. The flaw arises from improper synchronization mechanisms between reuseport allocation, addition, and detachment operations, leading to potential race conditions in SCTP socket management. The reported null-ptr-deref happens when accessing sk2->sk_reuseport_cb, which gets cleared concurrently by reuseport_detach_sock() during socket closure while reuseport_add_sock() attempts to access it. This vulnerability directly relates to CWE-476, which addresses null pointer dereference issues, and can be mapped to ATT&CK technique T1499.004, concerning network denial of service attacks through kernel-level memory corruption.
The core technical flaw stems from SCTP's failure to properly synchronize the reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock() functions, creating a scenario where multiple identical reuseport groups can form concurrently. When two sockets call listen() simultaneously on the same port, and one is closed while the other is being added, the lack of proper locking in __sctp_hash_endpoint() and __sctp_unhash_endpoint() functions allows for inconsistent state management. This results in sockets being classified into multiple reuseport groups, where only one group actually receives incoming packets, while others become silently dead. The problem is exacerbated because unlike TCP/UDP implementations that use hash bucket locking to prevent such scenarios, SCTP lacks this protective mechanism, making it vulnerable to concurrent access patterns that lead to memory corruption.
The operational impact of this vulnerability extends beyond simple denial of service, as it can potentially lead to system instability and memory corruption that might be exploited by malicious actors. An attacker could leverage this race condition to cause kernel crashes or potentially escalate privileges through controlled exploitation of the null pointer dereference. The vulnerability is particularly concerning in high-throughput environments where multiple concurrent socket operations are common, such as web servers or network services handling numerous connections. The reported crash occurs during the sctp_listen_start() function when it calls sctp_hash_endpoint(), which in turn invokes __sctp_hash_endpoint() and eventually triggers the null pointer dereference in reuseport_add_sock().
Mitigation strategies for this vulnerability involve implementing proper locking mechanisms around the reuseport operations to ensure atomicity during socket group management. The fix should include applying the same locking strategy used by TCP/UDP implementations to __sctp_hash_endpoint() and __sctp_unhash_endpoint() functions, ensuring that all sockets classified into the same reuseport group undergo synchronized access. System administrators should prioritize applying the kernel patches that address this specific synchronization issue, as the vulnerability affects the core networking stack and could lead to system instability. Additionally, monitoring for concurrent socket operations involving SO_REUSEPORT and implementing rate limiting or connection pooling strategies can help reduce the likelihood of triggering this race condition in production environments. The fix aligns with security best practices outlined in the Linux kernel security documentation and addresses the fundamental synchronization deficiencies in SCTP's reuseport implementation.