CVE-2024-26741 in Linux
Summary
by MITRE • 04/03/2024
In the Linux kernel, the following vulnerability has been resolved:
dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
syzkaller reported a warning [0] in inet_csk_destroy_sock() with no
repro.
WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash);
However, the syzkaller's log hinted that connect() failed just before the warning due to FAULT_INJECTION. [1]
When connect() is called for an unbound socket, we search for an available ephemeral port. If a bhash bucket exists for the port, we call __inet_check_established() or __inet6_check_established() to check if the bucket is reusable.
If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num.
Later, we look up the corresponding bhash2 bucket and try to allocate it if it does not exist.
Although it rarely occurs in real use, if the allocation fails, we must revert the changes by check_established(). Otherwise, an unconnected socket could illegally occupy an ehash entry.
Note that we do not put tw back into ehash because sk might have already responded to a packet for tw and it would be better to free tw earlier under such memory presure.
[0]:
WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Modules linked in: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170
[1]:
FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3748) kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867) inet_bind2_bucket_create ---truncated---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/03/2025
The vulnerability identified as CVE-2024-26741 resides within the Linux kernel's implementation of the DCCP and TCP protocols, specifically in how the kernel handles socket binding and connection establishment. This flaw manifests as a potential inconsistency in socket hash table management during the connection process, leading to a scenario where an unconnected socket might illegally occupy an ehash entry. The issue arises from a sequence of operations involving ephemeral port allocation, hash bucket lookups, and socket state management, where a failure during the second hash bucket allocation can leave the socket in an inconsistent state. The kernel's warning message indicates that a socket is being destroyed while still having a non-zero port number but not being properly hashed in the binding hash table, which violates expected socket state consistency.
The root cause lies in the handling of the __inet_check_established() function call, which is used to verify if an ephemeral port can be reused during socket binding. When a socket attempts to connect using an unbound socket, the kernel searches for an available ephemeral port, checks if the corresponding bucket in the binding hash table is reusable, and if so, adds the socket to the ehash table and sets the port number. However, after this initial setup, the kernel attempts to allocate a second hash bucket (bhash2) for the connection. If this allocation fails, the socket should be reverted to its previous state, but the current implementation does not properly unhash the socket from the ehash table. This failure results in an inconsistent state where the socket appears to be bound but is not properly managed in the hash tables, potentially leading to resource leaks or hash table corruption. This vulnerability is categorized under CWE-691, which deals with insufficient control flow management, and aligns with ATT&CK technique T1484.2, related to Privilege Escalation through kernel exploitation.
The operational impact of this vulnerability is significant as it can lead to socket resource exhaustion, hash table corruption, and potential denial of service conditions in systems heavily reliant on network connections. Attackers could exploit this by repeatedly attempting connections that trigger the specific allocation failure scenario, leading to progressive resource consumption and system instability. The vulnerability is particularly concerning in high-throughput network environments or systems with limited memory resources where hash table entries are critical for performance. The kernel's fault injection mechanism used in the syzkaller test case demonstrates how memory allocation failures can trigger this condition, indicating that the vulnerability could be exploited through memory pressure or by using fault injection tools to simulate allocation failures. Mitigation strategies include applying the kernel patch that ensures proper unhashing of sockets from ehash when bhash2 allocation fails, implementing stricter memory management policies, and monitoring for unusual socket behavior patterns that might indicate hash table corruption. The fix ensures that when an allocation failure occurs after the socket has been added to the ehash table, the socket is properly removed from the hash table to maintain consistency and prevent resource leaks.