CVE-2026-98109: Bluetooth: hci_core: Fix race condition during device registration
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcicore: Fix race condition during device registration
In hciregisterdev(), the poweron work item is queued to hdev->reqworkqueue before initializing hdev->advmonitorsidr and registering the MSFT extension via msftregister(). For devices marked with quirks such as HCIQUIRKRAWDEVICE, the HCIUNCONFIGURED flag is set on the device. When the poweron work item runs concurrently on another CPU, hcipoweron() detects that the device is unconfigured and immediately invokes hcidevdoclose(), which calls msftdoclose().
Concurrently, msftregister() allocates the msft structure and exposes it to hdev->msftdata prior to calling mutexinit(&msft->filterlock). If msftdoclose() executes while hdev->msftdata is already assigned but the mutex has not yet been initialized, mutexlock(&msft->filterlock) operates on an uninitialized mutex, triggering a DEBUGLOCKS warning:
DEBUGLOCKSWARNON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at mutexlockcommon kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at mutexlock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: <TASK> msftdoclose+0x308/0x7b0 net/bluetooth/msft.c:693 hcidevclosesync+0x86b/0x10a0 net/bluetooth/hcisync.c:5522 hcidevdoclose net/bluetooth/hcicore.c:499 [inline] hcipoweron+0x32c/0x750 net/bluetooth/hcicore.c:937 processonework kernel/workqueue.c:3322 [inline] processscheduledworks+0xa8e/0x14e0 kernel/workqueue.c:3405 workerthread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 retfromfork+0x514/0xb70 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>
Fix this by moving the queuework() call in hciregisterdev() to after idrinit(&hdev->advmonitorsidr) and msftregister(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msftdata in msftregister() only after mutexinit(&msft->filterlock) has completed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Update the Bluetooth HCI registration code so msft_register() initializes mutex_filter_lock before assigning hdev->msft_data, and move the queue_work() call in hci_register_dev() until after hdev->req_workqueue, adv_monitors_idr, and the MSFT extension are fully initialized.
Event History
Frequently Asked Questions
Which Bluetooth devices are exposed to this race?
The described race applies to devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, which causes the HCI_UNCONFIGURED flag to be set. The vulnerable path occurs during registration when power-on work can run concurrently with MSFT extension registration.
What timing is required to trigger the issue?
The power_on work item must run on another CPU while device registration is still initializing the MSFT data. The failure occurs if the close path reaches msft_do_close() after hdev->msft_data is exposed but before msft->filter_lock has been initialized.
How can an affected system be identified?
A triggered race can produce a DEBUG_LOCKS warning when mutex_lock() operates on the uninitialized filter_lock. The reported warning includes DEBUG_LOCKS_WARN_ON(lock->magic != lock) and points to kernel/locking/mutex.c in __mutex_lock_common or __mutex_lock.