Linux Kernel hasta 5.15.148/6.1.77/6.6.16/6.7.4 MSG_OOB Handling kfree_skb denegación de servicio

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

Resumeninformación

Una vulnerabilidad clasificada como crítica ha sido encontrada en Linux Kernel hasta 5.15.148/6.1.77/6.6.16/6.7.4. Se ve afectada una función desconocida del componente MSG_OOB Handling. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esta vulnerabilidad está identificada como CVE-2024-26676. No hay ningún exploit disponible. Es recomendable actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.15.148/6.1.77/6.6.16/6.7.4 y clasificada como crítica. La función kfree_skb del componente MSG_OOB Handling es afectada por esta vulnerabilidad. Por 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. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Llame a kfree_skb() para unix_(sk)->oob_skb muerto en GC. syzbot informó una advertencia [0] en __unix_gc() con una reproducción, que crea un par de sockets y se envía el fd de un socket a sí mismo utilizando el par. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 Esto forma una referencia autocíclica ese GC finalmente debería desenredarse, pero no lo hace debido a la falta de manejo de MSG_OOB, lo que resulta en una pérdida de memoria. Recientemente, el commit 11498715f266 ("af_unix: Eliminar el código io_uring para GC.") eliminó el código inactivo de io_uring en GC y reveló el problema. El código se ejecutó en la etapa final de GC y movió incondicionalmente todos los candidatos de GC de gc_candidates a gc_inflight_list. Eso ocultó el problema informado haciendo siempre que lo siguiente WARN_ON_ONCE(!list_empty(&gc_candidates)) fuera falso. El problema ha estado ahí desde que el commit 2aab4b969002 ("af_unix: corrige fugas de struct pid en soporte OOB") agregó soporte completo de scm para MSG_OOB mientras solucionaba otro error. Para solucionar este problema, debemos llamar a kfree_skb() para unix_sk(sk)->oob_skb si el socket todavía existe en gc_candidates después de purgar el skb recopilado. Luego, necesitamos establecer NULL en oob_skb antes de llamar a kfree_skb() porque llama al último fput() y activa unix_release_sock(), donde llamamos al duplicado kfree_skb(u->oob_skb) si no es NULL. Tenga en cuenta que el socket filtrado seguía vinculado a una lista global, por lo que kmemleak tampoco pudo detectarlo. Necesitamos verificar /proc/net/protocol para notar el socket no liberado. [0]: ADVERTENCIA: CPU: 0 PID: 2863 en net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Módulos vinculados en: CPU: 0 PID: 2863 Comm: kworker/ u4:11 No contaminado 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Cola de trabajo: events_unbound __unix_gc RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Código: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff c9000b03fc10 RCX: ffffffff816c493e RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 R10: 00000000000000003 R11: 00000000000000002 R12: dffffc 0000000000 R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:000 0000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000 00000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: Process_one_work+0x889/0x15e0 kernel/workqueue.c :2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] work_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process. c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-26676. Es difícil de explotar. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.

Una actualización a la versión 5.15.149, 6.1.78, 6.6.17, 6.7.5 o 6.8 elimina esta vulnerabilidad. Aplicando el parche 4fe505c63aa3/e0e09186d882/b74aa9ce13d0/82ae47c5c3a6/1279f9d9dec2 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.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productoinformación

Escribe

• Operating System

Proveedor

• Linux

Nombre

• Kernel

Versión

• 5.15.148
• 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.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.7.0
• 6.7.1
• 6.7.2
• 6.7.3
• 6.7.4

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.1
VulDB Puntuación meta temporal: 5.0

VulDB Puntuación base: 4.8
VulDB Puntuación temporal: 4.6
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CNA Puntuación base: 5.5
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-401 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍

Físico: En parte
Local: Sí
Remoto: En parte

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.149/6.1.78/6.6.17/6.7.5/6.8
Parche: 4fe505c63aa3/e0e09186d882/b74aa9ce13d0/82ae47c5c3a6/1279f9d9dec2

Línea de tiempoinformación

2024-02-19 🔍
2024-04-02 +42 días 🔍
2024-04-02 +0 días 🔍
2024-11-05 +217 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-26676 (🔍)
GCVE (CVE): GCVE-0-2024-26676
GCVE (VulDB): GCVE-100-258971

Artículoinformación

Fecha de creación: 2024-04-02 09:49
Actualizado: 2024-11-05 21:30
Cambios: 2024-04-02 09:49 (58), 2024-11-05 21:30 (13)
Completo: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discusión

Interested in the pricing of exploits?

See the underground prices here!