<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T15:55:27.532892+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-11894</id>
    <title>CVE-2026-11894 — Double-free / use-after-free in Realtek BEE Bluetooth HCI driver `send()` error paths</title>
    <updated>2026-09-30T15:55:27.545215+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> zephyrproject zephyr</p>
<p>The Realtek BEE Bluetooth HCI driver's send callback, bt_hci_bee_send() in drivers/bluetooth/hci/hci_bee.c, violated the bt_hci_driver_api buffer-ownership contract. That contract requires the driver to consume (unref) the transmit net_buf only on success; on an error return the host caller retains ownership and unrefs the buffer itself. The pre-fix code routed all error paths through a shared cleanup label that unconditionally called net_buf_unref(buf) before returning the error code.</p>
<p>Because the host TX paths (in subsys/bluetooth/host/hci_core.c) unref the buffer again after send() returns an error, the buffer is freed twice: the driver returns it to its net_buf pool and the host then unrefs the already-freed buffer, corrupting the shared pool / underflowing the reference count (CWE-415). The same error branch additionally dereferenced buf-&gt;len inside a LOG_ERR call after the buffer had already been unref'd, a read of freed memory (CWE-416) that is compiled in at the default error log level.</p>
<p>The failing edges are reached when the controller's host-to-controller buffer allocation fails or the controller send fails (resource-exhaustion / IO conditions). A remote Bluetooth peer can push the device toward these conditions indirectly by driving heavy host transmit activity, at which point the double-free corrupts the host net_buf pool and most likely crashes the device, with residual potential for further memory corruption. The impact is confined to builds using this specific…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-11894"/>
  </entry>
</feed>
