// For flags

CVE-2024-35970

af_unix: Clear stale u->oob_skb.

Severity Score

6.3
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Borrar u->oob_skb obsoleto. syzkaller comenzó a informar un punto muerto de unix_gc_lock después de la confirmación 4090fa373f0e ("af_unix: Reemplazar el algoritmo de recolección de basura"), pero simplemente descubre el error que ha estado ahí desde la confirmación 314001f0bf92 ("af_unix: Agregar soporte OOB"). La reproducción básicamente hace lo siguiente. desde importación de socket * desde matriz de importación matriz c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()])) ], MSG_OOB) c2.recv(1) # bloqueado porque no hay datos normales en la cola de recepción c2.close() # hecho asíncrono y desbloquea recv() c1.close() # hecho asíncrono y activa GC Un socket envía su descriptor de archivo a como datos OOB e intenta recibir datos normales, pero finalmente recv() falla debido al cierre asíncrono(). El problema aquí es el manejo incorrecto de OOB skb en Manage_oob(). Cuando se llama a recvmsg() sin MSG_OOB, se llama a Manage_oob() para verificar si el skb visto es skb OOB. En tal caso, Manage_oob() lo saca de la cola de recepción pero no borra unix_sock(sk)->oob_skb. Esto está mal en términos de uAPI. Digamos que enviamos "hola" con MSG_OOB y "mundo" sin MSG_OOB. La 'o' se maneja como datos OOB. Cuando se llama a recv() dos veces sin MSG_OOB, los datos OOB deberían perderse. >>> desde importación de socket * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' son datos OOB 5 >>> c1.send (b'world') 5 >>> c2.recv(5) # Los datos OOB no se reciben b'hell' >>> c2.recv(5) # La fecha OOB se omite b'world' >>> c2.recv (5, MSG_OOB) # Esto debería devolver un error b'o'. En la misma situación, TCP en realidad devuelve -EINVAL para el último recv(). Además, si no borramos unix_sk(sk)->oob_skb, unix_poll() siempre establece EPOLLPRI aunque los datos hayan pasado por el recv() anterior. Para evitar estos problemas, debemos borrar unix_sk(sk)->oob_skb al retirarlo de la cola de recepción. La razón por la que el antiguo GC no provocó el punto muerto es porque el antiguo GC dependía de la cola de recepción para detectar el bucle. Cuando se activa, el socket con datos OOB se marca como candidato de GC porque el recuento de archivos == recuento en vuelo (1). Sin embargo, después de atravesar todos los sockets en vuelo, el socket todavía tiene un recuento positivo en vuelo (1), por lo que el socket queda excluido de los candidatos. Entonces, el antiguo GC pierde la oportunidad de recolectar basura en el socket. Con el antiguo GC, la reproducción continúa creando verdadera basura que kmemleak nunca liberará ni detectará, ya que está vinculada a la lista global a bordo. Por eso ni siquiera pudimos notar el problema.

*Credits: N/A
CVSS Scores
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-17 CVE Reserved
  • 2024-05-20 CVE Published
  • 2024-05-21 EPSS Updated
  • 2024-12-19 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.15 < 5.15.156
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.15 < 5.15.156"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.15 < 6.1.87
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.15 < 6.1.87"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.15 < 6.6.28
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.15 < 6.6.28"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.15 < 6.8.7
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.15 < 6.8.7"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.15 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.15 < 6.9"
en
Affected