cbcvebase.
CVE-2024-35970
published 2024-05-20

CVE-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…

PriorityP434medium6.3CVSS 3.1
AVNACLPRLUINSUCLILAL
EPSS
0.50%
40.0th percentile
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 r

Affected

18 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.90-1 (bookworm)linux 6.1.90-1 (bookworm)
googleandroid
linuxlinux
linuxlinux>= 314001f0bf927015e459c9d387d62a231fe93af3 < b4bc99d04c689b5652665394ae8d3e02fb754153b4bc99d04c689b5652665394ae8d3e02fb754153
linuxlinux>= 314001f0bf927015e459c9d387d62a231fe93af3 < 84a352b7eba1142a95441380058985ff19f25ec984a352b7eba1142a95441380058985ff19f25ec9
linuxlinux>= 314001f0bf927015e459c9d387d62a231fe93af3 < 601a89ea24d05089debfa2dc896ea9f5937ac7a6601a89ea24d05089debfa2dc896ea9f5937ac7a6
linuxlinux>= 314001f0bf927015e459c9d387d62a231fe93af3 < 698a95ade1a00e6494482046902b986dfffd1caf698a95ade1a00e6494482046902b986dfffd1caf
linuxlinux>= 314001f0bf927015e459c9d387d62a231fe93af3 < b46f4eaa4f0ec38909fb0072eea3aeddb32f954eb46f4eaa4f0ec38909fb0072eea3aeddb32f954e
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.1.90-16.1.90-1
linuxlinux_kernel>= 0 < 6.8.9-16.8.9-1
linuxlinux_kernel>= 0 < 6.8.9-16.8.9-1
linuxlinux_kernel>= 0 < 5.15.0-116.1265.15.0-116.126
linuxlinux_kernel>= 0 < 6.8.0-38.386.8.0-38.38
linuxlinux_kernel>= 5.15 < 5.15.1565.15.156
linuxlinux_kernel>= 5.16 < 6.1.876.1.87
linuxlinux_kernel>= 6.2 < 6.6.286.6.28
linuxlinux_kernel>= 6.7 < 6.8.76.8.7

CVSS provenance

nvdv3.16.3MEDIUMCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
osv6.8MEDIUM
vendor_debian6.3MEDIUM
vendor_redhat6.3MEDIUM
vendor_ubuntu6.3MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.