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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-98109)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-98109)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
474751	Chainguard: linux-desktop-7.2-bootc: security update to 7.2.7-r0	Tenable Cloud Security	Chainguard Local Security Checks	Local	medium
474751	Chainguard: linux-desktop-7.2-bootc: security update to 7.2.7-r0	Tenable Self-Hosted Container Security	Chainguard Local Security Checks	Local	medium
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
350477	Linux Distros Unpatched Vulnerability : CVE-2026-98109	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-98109

medium

Tenable Plugins

medium

medium

high

high

high

medium