<?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>Fri, 13 Nov 2026 03:49:22 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-90832</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-90832</link>
      <description>&lt;p&gt;bt_hci_le_per_adv_report_common() in subsys/bluetooth/host/scan.c handles the HCI_LE_Periodic_Advertising_Report (and _v2) event. It verified that the fixed event header was present and that the controller-declared Data_Length fits the tailroom of the periodic-sync reassembly buffer, but never checked that the event actually carried as many data bytes as evt-&amp;gt;length claims. Both reassembly paths — DATA_STATUS_PARTIAL, and DATA_STATUS_COMPLETE while a chain is already in progress — then called net_buf_simple_add_mem(&amp;amp;per_adv_sync-&amp;gt;reassembly, buf-&amp;gt;data, evt-&amp;gt;length), copying up to 255 bytes starting past the end of the event&amp;#39;s real payload.&lt;/p&gt;
&lt;p&gt;The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent&amp;#39;s internal length field, so nothing else catches it. Builds using Zephyr&amp;#39;s own in-image controller are not affected, because the controller always emits a length matching the bytes it appends.&lt;/p&gt;
&lt;p&gt;Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE &amp;gt; 0 (the option defaults to 0, which compiles the r…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;bt_hci_le_per_adv_report_common() in subsys/bluetooth/host/scan.c handles the HCI_LE_Periodic_Advertising_Report (and _v2) event. It verified that the fixed event header was present and that the controller-declared Data_Length fits the tailroom of the periodic-sync reassembly buffer, but never checked that the event actually carried as many data bytes as evt-&amp;gt;length claims. Both reassembly paths — DATA_STATUS_PARTIAL, and DATA_STATUS_COMPLETE while a chain is already in progress — then called net_buf_simple_add_mem(&amp;amp;per_adv_sync-&amp;gt;reassembly, buf-&amp;gt;data, evt-&amp;gt;length), copying up to 255 bytes starting past the end of the event&amp;#39;s real payload.&lt;/p&gt;
&lt;p&gt;The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent&amp;#39;s internal length field, so nothing else catches it. Builds using Zephyr&amp;#39;s own in-image controller are not affected, because the controller always emits a length matching the bytes it appends.&lt;/p&gt;
&lt;p&gt;Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE &amp;gt; 0 (the option defaults to 0, which compiles the r…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-90832</guid>
    </item>
  </channel>
</rss>
