<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 15:42:24 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98109</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-98109</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_core: Fix race condition during device registration&lt;/p&gt;
&lt;p&gt;In hci_register_dev(), the power_on work item is queued to
hdev-&amp;gt;req_workqueue before initializing hdev-&amp;gt;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().&lt;/p&gt;
&lt;p&gt;Concurrently, msft_register() allocates the msft structure and exposes it
to hdev-&amp;gt;msft_data prior to calling mutex_init(&amp;amp;msft-&amp;gt;filter_lock). If
msft_do_close() executes while hdev-&amp;gt;msft_data is already assigned but the
mutex has not yet been initialized, mutex_lock(&amp;amp;msft-&amp;gt;filter_lock) operates
on an uninitialized mutex, triggering a DEBUG_LOCKS warning:&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;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:
 &amp;lt;TASK&amp;gt;
 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 [inli…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_core: Fix race condition during device registration&lt;/p&gt;
&lt;p&gt;In hci_register_dev(), the power_on work item is queued to
hdev-&amp;gt;req_workqueue before initializing hdev-&amp;gt;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().&lt;/p&gt;
&lt;p&gt;Concurrently, msft_register() allocates the msft structure and exposes it
to hdev-&amp;gt;msft_data prior to calling mutex_init(&amp;amp;msft-&amp;gt;filter_lock). If
msft_do_close() executes while hdev-&amp;gt;msft_data is already assigned but the
mutex has not yet been initialized, mutex_lock(&amp;amp;msft-&amp;gt;filter_lock) operates
on an uninitialized mutex, triggering a DEBUG_LOCKS warning:&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;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:
 &amp;lt;TASK&amp;gt;
 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 [inli…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-98109</guid>
    </item>
    <item>
      <title>GHSA-2gv9-7823-fxfm</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-2gv9-7823-fxfm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_core: Fix race condition during device registration&lt;/p&gt;
&lt;p&gt;In hci_register_dev(), the power_on work item is queued to
hdev-&amp;gt;req_workqueue before initializing hdev-&amp;gt;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().&lt;/p&gt;
&lt;p&gt;Concurrently, msft_register() allocates the msft structure and exposes it
to hdev-&amp;gt;msft_data prior to calling mutex_init(&amp;amp;msft-&amp;gt;filter_lock). If
msft_do_close() executes while hdev-&amp;gt;msft_data is already assigned but the
mutex has not yet been initialized, mutex_lock(&amp;amp;msft-&amp;gt;filter_lock) operates
on an uninitialized mutex, triggering a DEBUG_LOCKS warning:&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;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:
 &amp;lt;TASK&amp;gt;
 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 [inli…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_core: Fix race condition during device registration&lt;/p&gt;
&lt;p&gt;In hci_register_dev(), the power_on work item is queued to
hdev-&amp;gt;req_workqueue before initializing hdev-&amp;gt;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().&lt;/p&gt;
&lt;p&gt;Concurrently, msft_register() allocates the msft structure and exposes it
to hdev-&amp;gt;msft_data prior to calling mutex_init(&amp;amp;msft-&amp;gt;filter_lock). If
msft_do_close() executes while hdev-&amp;gt;msft_data is already assigned but the
mutex has not yet been initialized, mutex_lock(&amp;amp;msft-&amp;gt;filter_lock) operates
on an uninitialized mutex, triggering a DEBUG_LOCKS warning:&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;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:
 &amp;lt;TASK&amp;gt;
 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 [inli…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-2gv9-7823-fxfm</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98109</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-98109</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;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-&amp;gt;req_workqueue before initializing hdev-&amp;gt;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-&amp;gt;msft_data prior to calling mutex_init(&amp;amp;msft-&amp;gt;filter_lock). If msft_do_close() executes while hdev-&amp;gt;msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&amp;amp;msft-&amp;gt;filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock-&amp;gt;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:  &amp;lt;TASK&amp;gt;  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]…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;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-&amp;gt;req_workqueue before initializing hdev-&amp;gt;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-&amp;gt;msft_data prior to calling mutex_init(&amp;amp;msft-&amp;gt;filter_lock). If msft_do_close() executes while hdev-&amp;gt;msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&amp;amp;msft-&amp;gt;filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock-&amp;gt;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:  &amp;lt;TASK&amp;gt;  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]…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-98109</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
