CVE-2026-63944

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync<br /> <br /> hci_le_create_cis_sync() dereferences conn-&gt;conn_timeout after releasing<br /> both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was<br /> obtained from an RCU-protected iteration over hdev-&gt;conn_hash.list and<br /> is not valid once these locks are dropped. A concurrent disconnect can<br /> free the hci_conn between the unlock and the dereference, causing a<br /> use-after-free read.<br /> <br /> The cancellation mechanism in hci_conn_del() cannot prevent this because<br /> hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:<br /> <br /> hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);<br /> <br /> While hci_conn_del() dequeues with data=conn:<br /> <br /> hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);<br /> <br /> Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never<br /> matches, and the pending work item is not cancelled.<br /> <br /> Fix this by saving conn-&gt;conn_timeout into a local variable while the<br /> locks are still held, so the stale conn pointer is never dereferenced<br /> after unlock.<br /> <br /> This is the same class of bug as the one fixed by commit 035c25007c9e<br /> ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which<br /> addressed the identical pattern in a different function.<br /> <br /> This vulnerability was identified using 0sec.ai, an open-source<br /> automated security auditing platform (https://github.com/0sec-labs).