<?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://cve.radiocsirt.org</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, 06 Oct 2026 08:32:28 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-38250 — Bluetooth: hci_core: Fix use-after-free in vhci_flush()</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-38250</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: hci_core: Fix use-after-free in vhci_flush()&lt;/p&gt;
&lt;p&gt;syzbot reported use-after-free in vhci_flush() without repro. [0]&lt;/p&gt;
&lt;p&gt;From the splat, a thread close()d a vhci file descriptor while
its device was being used by iotcl() on another thread.&lt;/p&gt;
&lt;p&gt;Once the last fd refcnt is released, vhci_release() calls
hci_unregister_dev(), hci_free_dev(), and kfree() for struct
vhci_data, which is set to hci_dev-&amp;gt;dev-&amp;gt;driver_data.&lt;/p&gt;
&lt;p&gt;The problem is that there is no synchronisation after unlinking
hdev from hci_dev_list in hci_unregister_dev().  There might be
another thread still accessing the hdev which was fetched before
the unlink operation.&lt;/p&gt;
&lt;p&gt;We can use SRCU for such synchronisation.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s run hci_dev_reset() under SRCU and wait for its completion
in hci_unregister_dev().&lt;/p&gt;
&lt;p&gt;Another option would be to restore hci_dev-&amp;gt;destruct(), which was
removed in commit 587ae086f6e4 (&amp;#34;Bluetooth: Remove unused
hci-destruct cb&amp;#34;).  However, this would not be a good solution, as
we should not run hci_unregister_dev() while there are in-flight
ioctl() requests, which could lead to another data-race KCSAN splat.&lt;/p&gt;
&lt;p&gt;Note that other drivers seem to have the same problem, for exmaple,
virtbt_remove().&lt;/p&gt;
&lt;p&gt;[0]:
BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
Read of size 8 at addr ffff88807cb8d858 by task syz.1.21…&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: hci_core: Fix use-after-free in vhci_flush()&lt;/p&gt;
&lt;p&gt;syzbot reported use-after-free in vhci_flush() without repro. [0]&lt;/p&gt;
&lt;p&gt;From the splat, a thread close()d a vhci file descriptor while
its device was being used by iotcl() on another thread.&lt;/p&gt;
&lt;p&gt;Once the last fd refcnt is released, vhci_release() calls
hci_unregister_dev(), hci_free_dev(), and kfree() for struct
vhci_data, which is set to hci_dev-&amp;gt;dev-&amp;gt;driver_data.&lt;/p&gt;
&lt;p&gt;The problem is that there is no synchronisation after unlinking
hdev from hci_dev_list in hci_unregister_dev().  There might be
another thread still accessing the hdev which was fetched before
the unlink operation.&lt;/p&gt;
&lt;p&gt;We can use SRCU for such synchronisation.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s run hci_dev_reset() under SRCU and wait for its completion
in hci_unregister_dev().&lt;/p&gt;
&lt;p&gt;Another option would be to restore hci_dev-&amp;gt;destruct(), which was
removed in commit 587ae086f6e4 (&amp;#34;Bluetooth: Remove unused
hci-destruct cb&amp;#34;).  However, this would not be a good solution, as
we should not run hci_unregister_dev() while there are in-flight
ioctl() requests, which could lead to another data-race KCSAN splat.&lt;/p&gt;
&lt;p&gt;Note that other drivers seem to have the same problem, for exmaple,
virtbt_remove().&lt;/p&gt;
&lt;p&gt;[0]:
BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
Read of size 8 at addr ffff88807cb8d858 by task syz.1.21…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-38250</guid>
    </item>
  </channel>
</rss>
