Linux Kernel hasta 5.10.36/5.11.20/5.12.3 Bluetooth hci_conn_get_phy denegación de servicio

CVSS Puntuación meta temporalPrecio actual del exploit (≈)Puntuación de interés CTI
4.0$0-$5k0.00

Resumeninformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.10.36/5.11.20/5.12.3 y clasificada como problemática. Está afectada una función desconocida en el componente Bluetooth. El manejo da lugar a denegación de servicio. Esta vulnerabilidad se conoce como CVE-2021-47038. No hay ningún exploit disponible. Se recomienda actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.10.36/5.11.20/5.12.3 (Operating System) y clasificada como problemática. La función hci_conn_get_phy del componente Bluetooth 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. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: evitar interbloqueo entre hci_dev->lock y socket lock. el commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") agregó una dependencia entre socket lock y hci_dev->lock que podría provocar a un punto muerto. Resulta que hci_conn_get_phy() no depende de ninguna manera de que hdev sea inmutable durante el tiempo de ejecución de esta función, ni siquiera mira a ninguno de los miembros de hdev y, como tal, no es necesario mantener ese bloqueo. Esto soluciona el problema de bloqueo a continuación: ============================================ =========== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.12.0-rc1-00026-g73d464503354 #10 No contaminado ------------------- ----------------------------------- bluetoothd/1118 está intentando adquirir el bloqueo: ffff8f078383c078 (&hdev->lock ){+.+.}-{3:3}, en: hci_conn_get_phy+0x1c/0x150 [bluetooth] pero la tarea ya está bloqueada: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0 }, en: l2cap_sock_getsockopt+0x8b/0x610 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+ 0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] Process_one_work+0x244/0x5f0 trabajador_thread+0x3c/0x380 kthread+0 x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+ 0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0 x322/ 0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev- >bloquear){+.+.}-{ 3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc /0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/ 0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae otra información que podría ayudarnos a depurar esto: Existe cadena de: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Posible escenario de bloqueo inseguro: CPU0 CPU1 - --- ---- bloqueo(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); bloquear(&chan->bloquear#2/1); bloquear(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); bloquear(&hdev->bloquear); *** DEADLOCK *** 1 bloqueo retenido por bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, en: l2cap_sock_getsockopt+0x8b/0x610 pila [bluetooth] backtrace: CPU: 3 PID: 1118 Comm: bluetoothd No contaminado 5.12.0-rc1-00026-g73d464503354 #10 Nombre de hardware: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16) 31/05/2017 Seguimiento de llamadas: dump_stack+0x7 f/0xa1 check_noncircular+0x105/0x120? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50? lock_is_held_type+0xb4/0x120? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0? mark_held_locks+0x49/0x70? mark_held_locks+0x49/0x70? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x ---truncado---

La vulnerabilidad fue publicada el 2024-02-28 (confirmado). El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2021-47038. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.

Una actualización a la versión 5.10.37, 5.11.21, 5.12.4 o 5.13 elimina esta vulnerabilidad. Aplicando el parche 7cc0ba67883c/fee71f480bc1/332e69eb3bd9/17486960d79b 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

Proveedor

Nombre

Versión

Licencia

Sitio web

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 4.0
VulDB Puntuación meta temporal: 4.0

VulDB Puntuación base: 2.6
VulDB Puntuación temporal: 2.5
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 5.5
NVD Vector: 🔍

CVSSv2información

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplejidadAutenticaciónConfidencialidadIntegridadDisponibilidad
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear

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

Explotacióninformación

Clase: Denegación de servicio
CWE: CWE-833 / 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-DayDesbloquearDesbloquearDesbloquearDesbloquear
HoyDesbloquearDesbloquearDesbloquearDesbloquear

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.10.37/5.11.21/5.12.4/5.13
Parche: 7cc0ba67883c/fee71f480bc1/332e69eb3bd9/17486960d79b

Línea de tiempoinformación

2024-02-27 🔍
2024-02-28 +1 días 🔍
2024-02-28 +0 días 🔍
2024-12-06 +282 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2021-47038 (🔍)
GCVE (CVE): GCVE-0-2021-47038
GCVE (VulDB): GCVE-100-255075

Artículoinformación

Fecha de creación: 2024-02-28 11:25
Actualizado: 2024-12-06 22:23
Cambios: 2024-02-28 11:25 (44), 2024-12-06 22:23 (27)
Completo: 🔍
Cache ID: 216::103

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

Discusión

Sin comentarios aún. Idiomas: es + pt + en.

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Want to know what is going to be exploited?

We predict KEV entries!