CVE-2024-26732: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-26732

In the Linux kernel, the following vulnerability has been resolved: net: implement lockless setsockopt(SO_PEEK_OFF) syzbot reported a lockdep violation [1] involving af_unix support of SO_PEEK_OFF. Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket sk_peek_off field), there is really no point to enforce a pointless thread safety in the kernel. After this patch : - setsockopt(SO_PEEK_OFF) no longer acquires the socket lock. - skb_consume_udp() no longer has to acquire the socket lock. - af_unix no longer needs a special version of sk_set_peek_off(), because it does not lock u->iolock anymore. As a followup, we could replace prot->set_peek_off to be a boolean and avoid an indirect call, since we always use sk_set_peek_off(). [1] WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted syz-executor.2/30025 is trying to acquire lock: ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 but task is already holding lock: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_nested+0x48/0x100 net/core/sock.c:3524 lock_sock include/net/sock.h:1691 [inline] __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415 sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046 ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 -> #0 (&u->iolock){+.+.}-{3:3}: 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 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360 do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307 __sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_UNIX); lock(&u->iolock); lock(sk_lock-AF_UNIX); lock(&u->iolock); *** DEADLOCK *** 1 lock held by syz-executor.2/30025: #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 stack backtrace: CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google C ---truncated---

AI Analysis

Technical Summary

CVE-2024-26732 addresses a concurrency vulnerability in the Linux kernel related to the implementation of the SO_PEEK_OFF socket option, specifically within the AF_UNIX (Unix domain sockets) subsystem. The vulnerability arises from a lock dependency cycle involving two kernel locks: sk_lock (socket lock) and u->iolock (a lock specific to AF_UNIX sockets). The SO_PEEK_OFF option uses a per-socket field sk_peek_off that is inherently not thread-safe. Previously, the kernel enforced locking around setsockopt(SO_PEEK_OFF) calls to maintain thread safety, but this introduced a circular locking dependency between sk_lock and u->iolock. This circular dependency can lead to deadlocks, where two CPUs or threads wait indefinitely for each other’s locks, causing kernel hangs or degraded system responsiveness. The patch removes the acquisition of the socket lock during setsockopt(SO_PEEK_OFF) and related functions, eliminating the circular dependency and reducing locking overhead. This fix also simplifies the AF_UNIX socket code by removing the need for special locking around sk_set_peek_off(). The vulnerability was detected by syzbot, an automated kernel fuzzer, which reported a lockdep violation indicating the potential for deadlocks. The issue affects Linux kernel versions prior to the patch and is relevant to systems using Unix domain sockets with SO_PEEK_OFF. Although no direct exploit is known in the wild, the deadlock scenario could be triggered by malicious or buggy applications manipulating socket options concurrently, potentially leading to denial of service (DoS) conditions at the kernel level.

Potential Impact

For European organizations, this vulnerability primarily poses a risk of denial of service due to kernel deadlocks on systems running vulnerable Linux kernel versions. Many European enterprises, government agencies, and critical infrastructure providers rely heavily on Linux servers and embedded systems that utilize Unix domain sockets for inter-process communication. A deadlock in the kernel can cause system hangs, requiring reboots and resulting in service outages. This can disrupt business-critical applications, especially in sectors such as finance, telecommunications, healthcare, and manufacturing where Linux is prevalent. While the vulnerability does not directly enable privilege escalation or data breaches, the resulting DoS could be exploited as part of a broader attack chain or during targeted disruption campaigns. Additionally, embedded Linux devices used in industrial control systems or network equipment across Europe could be affected, impacting operational technology environments. The lack of a known exploit reduces immediate risk, but the potential for accidental or intentional triggering of deadlocks necessitates prompt remediation to maintain system stability and availability.

Mitigation Recommendations

European organizations should prioritize updating their Linux kernels to versions that include the patch for CVE-2024-26732. Kernel updates from trusted distributors (e.g., Debian, Ubuntu, Red Hat, SUSE) should be applied promptly, especially on servers and devices that use Unix domain sockets extensively. For environments where immediate patching is not feasible, administrators should audit applications and services that manipulate socket options, particularly SO_PEEK_OFF, to minimize concurrent setsockopt calls that could trigger the deadlock. Implementing kernel lock debugging and monitoring tools can help detect early signs of lock contention or deadlocks. Organizations should also review and harden access controls to limit untrusted users or processes from manipulating socket options. In embedded or specialized Linux deployments, vendors should be engaged to provide patched firmware or kernel updates. Finally, incorporating this vulnerability into incident response playbooks and system health checks will ensure rapid detection and remediation of related issues.