CVE-2024-26886

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: af_bluetooth: Reparar interbloqueo Intentar ejecutar sock_lock en .recvmsg puede causar un interbloqueo como se muestra a continuación, por lo que en lugar de usar sock_sock, usa sk_receive_queue.lock en bt_sock_ioctl para evitar el UAF: INFORMACIÓN: tarea kworker/u9:1:121 bloqueada durante más de 30 segundos. No contaminado 6.7.6-lemon #183 Cola de trabajo: hci0 hci_rx_work Seguimiento de llamadas: __schedule+0x37d/0xa00 Schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270? terminar_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 proceso_one_work+0x13a/0x2f0 trabajador_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

A flaw was found in the Linux kernel’s Bluetooth subsystem, specifically within the af_bluetooth module. The issue arises when attempting to perform a sock_lock on the .recvmsg method, leading to a deadlock situation. In this scenario, multiple tasks wait indefinitely for a resource, causing significant performance degradation or system crashes.
The vulnerability occurs during Bluetooth operations, where tasks are blocked for more than 30 seconds, creating potential instability. The solution was to replace the sock_sock lock with the sk_receive_queue.lock in the bt_sock_ioctl function to prevent a use-after-free (UAF) condition and avoid the deadlock.