Vulnerabilidad en kernel de Linux (CVE-2021-47038)

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---