<?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>Tue, 29 Sep 2026 07:21:46 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-72335 — Bluetooth: MGMT: Fix adv monitor add failure cleanup</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-72335</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: MGMT: Fix adv monitor add failure cleanup&lt;/p&gt;
&lt;p&gt;hci_add_adv_monitor() publishes a new adv_monitor in
hdev-&amp;gt;adv_monitors_idr before the powered MSFT setup step. The MSFT
offload add path can then fail either locally before the controller add
command completes, or in the MSFT add callback. In the current queued
management add flow, hci_cmd_sync_work() still invokes
mgmt_add_adv_patterns_monitor_complete() with the original pending command
after msft_add_monitor_pattern() returns.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the order
within that path:&lt;/p&gt;
&lt;p&gt;MSFT add handling                  MGMT completion
1. insert monitor and handle       1. receive sync error
2. send MSFT add command           2. call add-monitor completion
3. callback sees bad response      3. load cmd-&amp;gt;user_data
4. callback frees monitor          4. read monitor-&amp;gt;handle&lt;/p&gt;
&lt;p&gt;Local MSFT setup failures have the other half of the same ownership bug:
they return an error after the IDR insertion, but no later code removes the
failed monitor from the IDR.&lt;/p&gt;
&lt;p&gt;Keep ownership with the pending management command until its completion.
For normal management adds, the MSFT add callback now records successful
controller state and returns errors to its caller. The management
completion frees the monitor on non-success after copying the response
handle, while resume/reregister callback-error cleanup remains in the
MSFT callback. The succ…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: MGMT: Fix adv monitor add failure cleanup&lt;/p&gt;
&lt;p&gt;hci_add_adv_monitor() publishes a new adv_monitor in
hdev-&amp;gt;adv_monitors_idr before the powered MSFT setup step. The MSFT
offload add path can then fail either locally before the controller add
command completes, or in the MSFT add callback. In the current queued
management add flow, hci_cmd_sync_work() still invokes
mgmt_add_adv_patterns_monitor_complete() with the original pending command
after msft_add_monitor_pattern() returns.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the order
within that path:&lt;/p&gt;
&lt;p&gt;MSFT add handling                  MGMT completion
1. insert monitor and handle       1. receive sync error
2. send MSFT add command           2. call add-monitor completion
3. callback sees bad response      3. load cmd-&amp;gt;user_data
4. callback frees monitor          4. read monitor-&amp;gt;handle&lt;/p&gt;
&lt;p&gt;Local MSFT setup failures have the other half of the same ownership bug:
they return an error after the IDR insertion, but no later code removes the
failed monitor from the IDR.&lt;/p&gt;
&lt;p&gt;Keep ownership with the pending management command until its completion.
For normal management adds, the MSFT add callback now records successful
controller state and returns errors to its caller. The management
completion frees the monitor on non-success after copying the response
handle, while resume/reregister callback-error cleanup remains in the
MSFT callback. The succ…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-72335</guid>
    </item>
  </channel>
</rss>
