CVE-2026-98109 Bluetooth: hci_core: Fix race condition during device registration

Medium 4.7 Published Updated

A race condition in the Linux kernel Bluetooth subsystem can cause a kernel warning and potential denial of service during device registration.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Local or same network only
Victim action needed
Not needed
Fix
Available

What is CVE-2026-98109?

CVE-2026-98109 is a medium-severity vulnerability in Linux kernel, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

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.

Weakness: CWE-362

Which versions are affected by CVE-2026-98109?

It affects 1 product.

Products include Linux kernel.

How do I fix CVE-2026-98109?

Apply the vendor's patch.

Is CVE-2026-98109 being exploited?

There is no known exploitation of CVE-2026-98109 in the wild and no public exploit code.

All Linux kernel vulnerabilities

Sources

Also known as AZL-104412, BELL-CVE-2026-98109, DEBIAN-CVE-2026-98109, GHSA-2gv9-7823-fxfm, UBUNTU-CVE-2026-98109.

Is CVE-2026-98109 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free