<?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://db.gcve.eu</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>Sun, 25 Oct 2026 15:35:13 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-99013 — Bluetooth: ISO: Reject concurrent BIS listener setup</title>
      <link>https://db.gcve.eu/vuln/cve-2026-99013</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: ISO: Reject concurrent BIS listener setup&lt;/p&gt;
&lt;p&gt;iso_sock_listen() drops the socket lock before calling iso_listen_bis()
to preserve the hdev-&amp;gt;lock ordering. Two concurrent listen() calls on
the same broadcast socket can therefore both observe BT_BOUND. Caller
A can attach connA and release the locks, then caller B can acquire
them and attach connB before A publishes BT_LISTEN.&lt;/p&gt;
&lt;p&gt;__iso_chan_add() checks whether connB already has a socket, but not
whether the socket already has a connection. The second attachment
overwrites iso_pi(sk)-&amp;gt;conn, leaking the connA reference and leaving
connA-&amp;gt;sk intact. Socket teardown follows connB, so later events on
connA can cause a stale socket access.&lt;/p&gt;
&lt;p&gt;Recheck BT_BOUND and require iso_pi(sk)-&amp;gt;conn to be NULL after taking
both the HCI device and socket locks in iso_listen_bis(). The connection
check also covers the interval between attachment and publication of
BT_LISTEN. Reject a competing setup with -EBADFD through the existing
unlock path before allocating another connection.&lt;/p&gt;
&lt;p&gt;A recorded KASAN report from an instrumented kernel shows:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in iso_sock_hold+0x119/0x1f0
  Call Trace:
   iso_sock_hold+0x119/0x1f0
   iso_conn_del+0xe4/0x270
   hci_disconn_complete_evt+0x351/0x8c0
   hci_event_packet+0x71b/0xb20
   hci_rx_work+0x293/0x730&lt;/p&gt;
&lt;p&gt;Allocated by task 93:
   sk_prot_alloc+0x113/0x220
   sk_alloc+0x2b/0x6d0
   bt_sock_alloc+0x29/0x370…&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: ISO: Reject concurrent BIS listener setup&lt;/p&gt;
&lt;p&gt;iso_sock_listen() drops the socket lock before calling iso_listen_bis()
to preserve the hdev-&amp;gt;lock ordering. Two concurrent listen() calls on
the same broadcast socket can therefore both observe BT_BOUND. Caller
A can attach connA and release the locks, then caller B can acquire
them and attach connB before A publishes BT_LISTEN.&lt;/p&gt;
&lt;p&gt;__iso_chan_add() checks whether connB already has a socket, but not
whether the socket already has a connection. The second attachment
overwrites iso_pi(sk)-&amp;gt;conn, leaking the connA reference and leaving
connA-&amp;gt;sk intact. Socket teardown follows connB, so later events on
connA can cause a stale socket access.&lt;/p&gt;
&lt;p&gt;Recheck BT_BOUND and require iso_pi(sk)-&amp;gt;conn to be NULL after taking
both the HCI device and socket locks in iso_listen_bis(). The connection
check also covers the interval between attachment and publication of
BT_LISTEN. Reject a competing setup with -EBADFD through the existing
unlock path before allocating another connection.&lt;/p&gt;
&lt;p&gt;A recorded KASAN report from an instrumented kernel shows:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in iso_sock_hold+0x119/0x1f0
  Call Trace:
   iso_sock_hold+0x119/0x1f0
   iso_conn_del+0xe4/0x270
   hci_disconn_complete_evt+0x351/0x8c0
   hci_event_packet+0x71b/0xb20
   hci_rx_work+0x293/0x730&lt;/p&gt;
&lt;p&gt;Allocated by task 93:
   sk_prot_alloc+0x113/0x220
   sk_alloc+0x2b/0x6d0
   bt_sock_alloc+0x29/0x370…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-99013</guid>
    </item>
  </channel>
</rss>
