CVE-2024-35970: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-35970

In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.

AI Analysis

Technical Summary

CVE-2024-35970 is a medium severity vulnerability in the Linux kernel's AF_UNIX socket implementation related to the handling of out-of-band (OOB) data in UNIX domain sockets. The flaw arises from improper management of the OOB socket buffer (oob_skb) in the function manage_oob(). Specifically, when recvmsg() is called without the MSG_OOB flag, manage_oob() checks if the peeked socket buffer (skb) is OOB data. If so, it removes the skb from the receive queue but fails to clear the unix_sock(sk)->oob_skb pointer. This leads to inconsistencies with the user API (uAPI) expectations, where OOB data should be discarded if not explicitly requested, and the socket state should reflect that no OOB data remains. The vulnerability manifests in scenarios where a socket sends its own file descriptor as OOB data to itself and attempts to receive normal data, causing recv() to fail due to asynchronous socket closure and mishandling of OOB skb. This improper clearing also causes unix_poll() to continuously signal EPOLLPRI events, even after the OOB data has been consumed, potentially leading to resource mismanagement or unexpected application behavior. Additionally, the vulnerability interacts with the garbage collection (GC) algorithm for AF_UNIX sockets. The older GC algorithm did not trigger deadlocks but failed to detect and free certain garbage sockets, causing memory leaks. The newer GC algorithm exposed a deadlock condition on the unix_gc_lock due to the stale oob_skb references, which was reported by syzkaller. The root cause is the stale oob_skb pointer not being cleared when the OOB skb is dequeued, violating expected socket state transitions and causing both deadlock and resource leakage issues. This vulnerability affects Linux kernel versions starting from commit 314001f0bf92 and was publicly disclosed on May 20, 2024. It requires local privileges (PR:L) to exploit, does not require user interaction, and can be triggered remotely on the same host via UNIX domain sockets. The CVSS v3.1 score is 6.3 (medium severity), reflecting its impact on confidentiality, integrity, and availability due to potential denial of service or information leakage through socket state corruption and deadlocks.

Potential Impact

For European organizations, this vulnerability poses a moderate risk primarily to systems running Linux kernels with the affected commits, especially those utilizing UNIX domain sockets for inter-process communication (IPC). The improper handling of OOB data can lead to denial of service conditions via deadlocks or resource exhaustion, impacting critical services relying on IPC such as container runtimes, microservices architectures, and system daemons. Confidentiality and integrity impacts are limited but possible if attackers can manipulate socket states to interfere with data flows or cause unexpected application behavior. The vulnerability requires local privilege, so it is mainly a concern in multi-user environments, shared hosting, or containerized systems where untrusted users or processes may attempt exploitation. European enterprises with extensive Linux server deployments, cloud infrastructure, or embedded Linux devices could face service disruptions or increased attack surface if not patched. The continuous EPOLLPRI signaling may also cause performance degradation or complicate incident response. Although no known exploits are reported in the wild, the presence of a syzkaller-detected deadlock suggests the vulnerability could be weaponized by skilled attackers to cause denial of service or escalate local attacks. Given the widespread use of Linux in European critical infrastructure, telecommunications, and enterprise IT, timely mitigation is important to maintain service availability and system integrity.

Mitigation Recommendations

1. Apply the official Linux kernel patches that fix CVE-2024-35970 as soon as they become available from trusted sources or Linux distribution vendors. Monitor vendor advisories for updated kernel packages. 2. For environments where immediate patching is not feasible, restrict local user access to systems running vulnerable kernels to trusted personnel only, minimizing the risk of local exploitation. 3. Audit and limit the use of UNIX domain sockets with OOB data in applications, especially those exposed to untrusted users or containers. 4. Implement strict container isolation and privilege restrictions to prevent unprivileged processes from exploiting local IPC mechanisms. 5. Monitor system logs and socket activity for unusual EPOLLPRI events or deadlock symptoms that could indicate exploitation attempts. 6. Employ runtime security tools capable of detecting kernel deadlocks or resource leaks related to socket garbage collection. 7. Consider kernel hardening features or security modules that limit socket operations or enforce stricter IPC controls. 8. Engage in proactive fuzz testing or use syzkaller-like tools internally to detect similar IPC-related kernel issues early. These steps go beyond generic advice by focusing on local access control, IPC usage auditing, and runtime detection tailored to the vulnerability's characteristics.