Linux Kernel hasta 5.15.155/6.1.86/6.6.27/6.8.6 af_unix denegación de servicio

CVSS Puntuación meta temporal	Precio actual del exploit (≈)	Puntuación de interés CTI
5.8	$0-$5k	0.00

Resumeninformación

Se ha detectado una vulnerabilidad clasificada como problemática en Linux Kernel hasta 5.15.155/6.1.86/6.6.27/6.8.6. Está afectada una función desconocida en el componente af_unix. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esta vulnerabilidad se cataloga como CVE-2024-35970. No existe ningún exploit disponible. Se aconseja actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como problemática ha sido encontrada en Linux Kernel hasta 5.15.155/6.1.86/6.6.27/6.8.6. Una función desconocida del componente af_unix es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esto tiene repercusión sobre la la disponibilidad. CVE resume:

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.

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-35970. No se conoce los detalles técnicos ni hay ningún exploit disponible.

Una actualización a la versión 5.15.156, 6.1.87, 6.6.28 o 6.8.7 elimina esta vulnerabilidad. Aplicando el parche b4bc99d04c68/84a352b7eba1/601a89ea24d0/698a95ade1a0/b46f4eaa4f0e es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.

La vulnerabilidad también está documentado en la base de datos CERT Bund (WID-SEC-2025-2711). VulDB is the best source for vulnerability data and more expert information about this specific topic.

Afectado

• Lenovo BIOS
• Lenovo Computer
• Google Android

Productoinformación

Escribe

• Operating System

Proveedor

• Linux

Nombre

• Kernel

Versión

• 5.15.155
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.1.28
• 6.1.29
• 6.1.30
• 6.1.31
• 6.1.32
• 6.1.33
• 6.1.34
• 6.1.35
• 6.1.36
• 6.1.37
• 6.1.38
• 6.1.39
• 6.1.40
• 6.1.41
• 6.1.42
• 6.1.43
• 6.1.44
• 6.1.45
• 6.1.46
• 6.1.47
• 6.1.48
• 6.1.49
• 6.1.50
• 6.1.51
• 6.1.52
• 6.1.53
• 6.1.54
• 6.1.55
• 6.1.56
• 6.1.57
• 6.1.58
• 6.1.59
• 6.1.60
• 6.1.61
• 6.1.62
• 6.1.63
• 6.1.64
• 6.1.65
• 6.1.66
• 6.1.67
• 6.1.68
• 6.1.69
• 6.1.70
• 6.1.71
• 6.1.72
• 6.1.73
• 6.1.74
• 6.1.75
• 6.1.76
• 6.1.77
• 6.1.78
• 6.1.79
• 6.1.80
• 6.1.81
• 6.1.82
• 6.1.83
• 6.1.84
• 6.1.85
• 6.1.86
• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.6.24
• 6.6.25
• 6.6.26
• 6.6.27
• 6.8.0
• 6.8.1
• 6.8.2
• 6.8.3
• 6.8.4
• 6.8.5
• 6.8.6

Licencia

• Código abierto

Sitio web

• Proveedor: https://www.kernel.org/

CPE 2.3información

• 🔍
• 🔍
• 🔍

CPE 2.2información

• 🔍
• 🔍
• 🔍

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 5.9
VulDB Puntuación meta temporal: 5.8

VulDB Puntuación base: 5.5
VulDB Puntuación temporal: 5.3
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CNA Puntuación base: 6.3
CNA Vector: 🔍

CVSSv2información

AV	AC	Au	C	I	A
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳

Vector	Complejidad	Autenticación	Confidencialidad	Integridad	Disponibilidad
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Denegación de servicio
CWE: CWE-769 / CWE-400 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍

Físico: No
Local: No
Remoto: Sí

Disponibilidad: 🔍
Estado: No está definido

EPSS Score: 🔍
EPSS Percentile: 🔍

Predicción de precios: 🔍
Estimación del precio actual: 🔍

0-Day	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Hoy	Desbloquear	Desbloquear	Desbloquear	Desbloquear

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 5.15.156/6.1.87/6.6.28/6.8.7
Parche: b4bc99d04c68/84a352b7eba1/601a89ea24d0/698a95ade1a0/b46f4eaa4f0e

Línea de tiempoinformación

2024-05-17 🔍
2024-05-20 +3 días 🔍
2024-05-20 +0 días 🔍
2025-12-11 +570 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-35970 (🔍)
GCVE (CVE): GCVE-0-2024-35970
GCVE (VulDB): GCVE-100-265248
CERT Bund: WID-SEC-2025-2711 - Android Patchday Dezember 2025: Mehrere Schwachstellen

Artículoinformación

Fecha de creación: 2024-05-20 12:35
Actualizado: 2025-12-11 05:57
Cambios: 2024-05-20 12:35 (56), 2024-11-02 05:45 (13), 2025-12-11 05:57 (7)
Completo: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Discusión

Do you need the next level of professionalism?

Upgrade your account now!