CVE-2026-98109

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: Fix race condition during device registration

In hci_register_dev(), the power_on work item is queued to

hdev->req_workqueue before initializing hdev->adv_monitors_idr and

registering the MSFT extension via msft_register(). For devices marked with

quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on

the device. When the power_on work item runs concurrently on another CPU,

hci_power_on() detects that the device is unconfigured and immediately

invokes hci_dev_do_close(), which calls msft_do_close().

Concurrently, msft_register() allocates the msft structure and exposes it

to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If

msft_do_close() executes while hdev->msft_data is already assigned but the

mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates

on an uninitialized mutex, triggering a DEBUG_LOCKS warning:

DEBUG_LOCKS_WARN_ON(lock->magic != lock)

WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common

kernel/locking/mutex.c:625 [inline]

WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550

kernel/locking/mutex.c:821

...

Call Trace:

<TASK>

msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693

hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522

hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]

hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937

process_one_work kernel/workqueue.c:3322 [inline]

process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405

worker_thread+0x92d/0xe10 kernel/workqueue.c:3486

kthread+0x388/0x470 kernel/kthread.c:436

ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158

ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

</TASK>

Fix this by moving the queue_work() call in hci_register_dev() to after

idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device

structures and extensions are fully initialized before asynchronous tasks

can access them. Additionally, assign hdev->msft_data in msft_register()

only after mutex_init(&msft->filter_lock) has completed.