CVE-2026-63944

HIGHCVSS 8.8/10EPSS 0.32%

Last modified

CVE-2026-63944 is a high-severity vulnerability rated 8.8/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->conn_hash.list and is not valid once these locks are dropped. EPSS estimates a 0.32% chance of exploitation in the next 30 days.

Description

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

Metrics

CVSS 3.1
8.8/10

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS Probability
0.32%

24.8th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= c09b80be6ffc338634b2f5f8cfa12b6843410834, < a55618c0f4cead9e59c63f5ee030d393fd70d861; >= c09b80be6ffc338634b2f5f8cfa12b6843410834, < a921957d39290143629eb38c4f74b9bef8035d0a; >= c09b80be6ffc338634b2f5f8cfa12b6843410834, < d9019210c8c30d40eb20094274cc647e352f48f7; >= c09b80be6ffc338634b2f5f8cfa12b6843410834, < 380e67b1794a9a281a0cb592b4e62077fbd0c8ca; >= c09b80be6ffc338634b2f5f8cfa12b6843410834, < bfea6091e0fffb270c20e74384b660910277eb6c
LinuxLinux6.4

References

Timeline

Published
Last Modified
Status
Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-63944?
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->conn_hash.list and is not valid once these locks are dropped. A concurrent disconnect can free the hci_conn between the unlock and the dereference, causing a use-after-free read. The cancellation mechanism in hci_conn_del() cannot prevent this because hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL: hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL); While hci_conn_del() dequeues with data=conn: hci_cmd_sync_dequeue(hdev, NULL, conn, NULL); Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never matches, and the pending work item is not cancelled. Fix this by saving conn->conn_timeout into a local variable while the locks are still held, so the stale conn pointer is never dereferenced after unlock. This is the same class of bug as the one fixed by commit 035c25007c9e ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which addressed the identical pattern in a different function. This vulnerability was identified using 0sec.ai, an open-source automated security auditing platform (https://github.com/0sec-labs).
How severe is CVE-2026-63944?
CVE-2026-63944 has a CVSS score of 8.8/10 (HIGH severity). The EPSS model estimates a 0.32% probability of exploitation in the next 30 days.
How do I fix CVE-2026-63944?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-63944?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST