UBUNTU-CVE-2026-98109: Race Condition
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.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In hci_register_dev(), move the queue_work() call until after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) have completed, ensuring device structures and extensions are fully initialized before asynchronous tasks can access them; in msft_register(), assign hdev->msft_data only after mutex_init(&msft->filter_lock) completes.
Event History
Frequently Asked Questions
Which Ubuntu kernel package families are listed as affected?
The listed packages are ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, ubuntu/linux-hwe-edge, and ubuntu/linux-gkeop.
What access and conditions are indicated for exploitation?
The CVSS vector indicates local access, low privileges, no user interaction, and high attack complexity. The described race involves Bluetooth devices marked with quirks such as HCI_QUIRK_RAW_DEVICE that result in the device being treated as unconfigured.
How might this issue appear on an affected system?
The described failure can trigger a DEBUG_LOCKS warning when mutex_lock operates on an uninitialized MSFT filter mutex. The example warning is "DEBUG_LOCKS_WARN_ON(lock->magic != lock)" in the kernel mutex locking code.