CVE-2025-68304

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: lookup hci_conn on RX path on protocol side<br /> <br /> The hdev lock/lookup/unlock/use pattern in the packet RX path doesn&amp;#39;t<br /> ensure hci_conn* is not concurrently modified/deleted. This locking<br /> appears to be leftover from before conn_hash started using RCU<br /> commit bf4c63252490b ("Bluetooth: convert conn hash to RCU")<br /> and not clear if it had purpose since then.<br /> <br /> Currently, there are code paths that delete hci_conn* from elsewhere<br /> than the ordered hdev-&gt;workqueue where the RX work runs in. E.g.<br /> commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")<br /> introduced some of these, and there probably were a few others before<br /> it. It&amp;#39;s better to do the locking so that even if these run<br /> concurrently no UAF is possible.<br /> <br /> Move the lookup of hci_conn and associated socket-specific conn to<br /> protocol recv handlers, and do them within a single critical section<br /> to cover hci_conn* usage and lookup.<br /> <br /> syzkaller has reported a crash that appears to be this issue:<br /> <br /> [Task hdev-&gt;workqueue] [Task 2]<br /> hci_disconnect_all_sync<br /> l2cap_recv_acldata(hcon)<br /> hci_conn_get(hcon)<br /> hci_abort_conn_sync(hcon)<br /> hci_dev_lock<br /> hci_dev_lock<br /> hci_conn_del(hcon)<br /> v-------------------------------- hci_dev_unlock<br /> hci_conn_put(hcon)<br /> conn = hcon-&gt;l2cap_data (UAF)