CVE-2024-35970
published 2024-05-20CVE-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…
medium6.3CVSS 3.1
AVNACLPRLUINSUCLILAL
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
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.90-1 (bookworm) | linux 6.1.90-1 (bookworm) |
| android | — | — | |
| linux | linux | — | — |
| linux | linux | >= 314001f0bf927015e459c9d387d62a231fe93af3 < b4bc99d04c689b5652665394ae8d3e02fb754153 | b4bc99d04c689b5652665394ae8d3e02fb754153 |
| linux | linux | >= 314001f0bf927015e459c9d387d62a231fe93af3 < 84a352b7eba1142a95441380058985ff19f25ec9 | 84a352b7eba1142a95441380058985ff19f25ec9 |
| linux | linux | >= 314001f0bf927015e459c9d387d62a231fe93af3 < 601a89ea24d05089debfa2dc896ea9f5937ac7a6 | 601a89ea24d05089debfa2dc896ea9f5937ac7a6 |
| linux | linux | >= 314001f0bf927015e459c9d387d62a231fe93af3 < 698a95ade1a00e6494482046902b986dfffd1caf | 698a95ade1a00e6494482046902b986dfffd1caf |
| linux | linux | >= 314001f0bf927015e459c9d387d62a231fe93af3 < b46f4eaa4f0ec38909fb0072eea3aeddb32f954e | b46f4eaa4f0ec38909fb0072eea3aeddb32f954e |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.90-1 | 6.1.90-1 |
| linux | linux_kernel | >= 0 < 6.8.9-1 | 6.8.9-1 |
| linux | linux_kernel | >= 0 < 6.8.9-1 | 6.8.9-1 |
| linux | linux_kernel | >= 0 < 5.15.0-116.126 | 5.15.0-116.126 |
| linux | linux_kernel | >= 0 < 6.8.0-38.38 | 6.8.0-38.38 |
| linux | linux_kernel | >= 5.15 < 5.15.156 | 5.15.156 |
| linux | linux_kernel | >= 5.16 < 6.1.87 | 6.1.87 |
| linux | linux_kernel | >= 6.2 < 6.6.28 | 6.6.28 |
| linux | linux_kernel | >= 6.7 < 6.8.7 | 6.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