CVE-2024-26781: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-26781

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix possible deadlock in subflow diag Syzbot and Eric reported a lockdep splat in the subflow diag: WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---

AI Analysis

Technical Summary

CVE-2024-26781 is a vulnerability identified in the Linux kernel, specifically within the Multipath TCP (MPTCP) subsystem's diagnostic code. The issue arises from a potential deadlock caused by a circular locking dependency in the subflow diagnostic functions. The problem was initially detected by Syzbot and a researcher named Eric, who observed a lockdep warning indicating a possible circular locking dependency. The vulnerability involves the kernel attempting to acquire a lock (k-sk_lock-AF_INET6) while already holding another lock (&h->lhash2[i].lock), which itself depends on the first lock, creating a circular dependency chain. This deadlock can occur during diagnostic operations related to TCP sockets, particularly when dumping diagnostic information about subflows in MPTCP. The detailed kernel stack traces show that the deadlock happens in functions such as tcp_diag_put_ulp, tcp_diag_get_aux, inet_diag_dump_icsk, and related netlink socket diagnostic routines. The root cause is a lock acquisition order violation that leads to a circular wait condition, potentially causing the kernel to hang or become unresponsive during diagnostic operations. The vulnerability affects multiple Linux kernel versions identified by specific commit hashes. Although no known exploits are currently reported in the wild, the issue could impact systems running vulnerable kernel versions, especially those utilizing MPTCP features. The fix involves breaking the lock dependency chain to prevent the deadlock during diagnostic dumps. Since this vulnerability is in the kernel's networking stack, it could affect any Linux-based system using affected kernel versions and MPTCP functionality.

Potential Impact

For European organizations, the impact of CVE-2024-26781 could be significant in environments where Linux servers or devices run vulnerable kernel versions with MPTCP enabled or in use. The deadlock can cause system hangs or kernel panics during diagnostic operations, potentially leading to denial of service (DoS) conditions. This can disrupt critical services such as web hosting, cloud infrastructure, telecommunications, and industrial control systems that rely on Linux servers. Organizations using MPTCP for network redundancy or performance improvements may experience degraded reliability or outages. Additionally, the inability to perform diagnostic operations reliably can hinder troubleshooting and incident response efforts. While the vulnerability does not directly lead to privilege escalation or data leakage, the availability impact on critical infrastructure and services can have cascading effects on business operations, regulatory compliance, and customer trust. Given the widespread use of Linux in European data centers, cloud providers, and embedded systems, the vulnerability poses a moderate to high risk if left unpatched.

Mitigation Recommendations

1. Apply the official Linux kernel patches that fix the circular locking dependency in the MPTCP subflow diagnostic code as soon as they become available from trusted sources or distributions. 2. For organizations using custom or long-term support kernels, backport the fix carefully to avoid introducing regressions. 3. Disable MPTCP functionality temporarily if it is not essential, to reduce exposure until patches are applied. 4. Monitor kernel logs for lockdep warnings or deadlock symptoms related to TCP diagnostics to detect potential exploitation or triggering of the issue. 5. Implement robust system monitoring and automated recovery mechanisms to detect and remediate kernel hangs or crashes promptly. 6. Coordinate with Linux distribution vendors to ensure timely updates and advisories are received and acted upon. 7. Conduct thorough testing of kernel updates in staging environments to verify stability and compatibility before production deployment. 8. Educate system administrators and security teams about this specific vulnerability to raise awareness and ensure rapid response.