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.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: af_bluetooth: Fix deadlock Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __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 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_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 </TASK>

Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde discovered that an untrusted hypervisor could inject malicious #VC interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw is known as WeSee. A local attacker in control of the hypervisor could use this to expose sensitive information or possibly execute arbitrary code in the trusted execution environment. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.