<?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>Fri, 02 Oct 2026 07:14:18 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-10658</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-10658</link>
      <description>&lt;p&gt;bt_iso_recv() in subsys/bluetooth/host/iso.c pulled the ISO SDU header (4 bytes) or, when the timestamp flag is set, the timestamped SDU header (8 bytes) from the inbound HCI ISO Data buffer via net_buf_pull_mem() without first checking buf-&amp;gt;len. The upstream hci_iso() handler enforces buf-&amp;gt;len == the controller-declared ISO Data_Load length, so a malicious or buggy controller / adjacent BLE peer on an established CIS/BIS can present a first-fragment (BT_ISO_START) or single (BT_ISO_SINGLE) PDU shorter than the SDU header. Because net_buf_simple_pull_mem only guards length with __ASSERT_NO_MSG (compiled out when CONFIG_ASSERT is disabled, the production default), the pull underflows buf-&amp;gt;len (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-&amp;gt;data past valid data: the subsequent reads of hdr-&amp;gt;slen and hdr-&amp;gt;sn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-&amp;gt;rx, and a following CONT/END fragment&amp;#39;s net_buf_tailroom() guard underflows to a near-SIZE_MAX value, defeating the bounds check and causing net_buf_add_mem() to memcpy attacker-supplied fragment data far past the RX pool buffer (out-of-bounds write). The flaw affects ISO receive builds (CONFIG_BT_ISO_RX, selected by the default-off LE Audio options BT_ISO_PERIPHERAL/BT_ISO_CENTRAL/BT_ISO_SYNC_RECEIVER) and has existed since the ISO subsystem was introduced (v2.6.0) through v4.4.0. The fix adds explicit buf-&amp;gt;len &amp;lt; sizeof(ts_hdr) and buf-&amp;gt;len &amp;lt; size…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;bt_iso_recv() in subsys/bluetooth/host/iso.c pulled the ISO SDU header (4 bytes) or, when the timestamp flag is set, the timestamped SDU header (8 bytes) from the inbound HCI ISO Data buffer via net_buf_pull_mem() without first checking buf-&amp;gt;len. The upstream hci_iso() handler enforces buf-&amp;gt;len == the controller-declared ISO Data_Load length, so a malicious or buggy controller / adjacent BLE peer on an established CIS/BIS can present a first-fragment (BT_ISO_START) or single (BT_ISO_SINGLE) PDU shorter than the SDU header. Because net_buf_simple_pull_mem only guards length with __ASSERT_NO_MSG (compiled out when CONFIG_ASSERT is disabled, the production default), the pull underflows buf-&amp;gt;len (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-&amp;gt;data past valid data: the subsequent reads of hdr-&amp;gt;slen and hdr-&amp;gt;sn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-&amp;gt;rx, and a following CONT/END fragment&amp;#39;s net_buf_tailroom() guard underflows to a near-SIZE_MAX value, defeating the bounds check and causing net_buf_add_mem() to memcpy attacker-supplied fragment data far past the RX pool buffer (out-of-bounds write). The flaw affects ISO receive builds (CONFIG_BT_ISO_RX, selected by the default-off LE Audio options BT_ISO_PERIPHERAL/BT_ISO_CENTRAL/BT_ISO_SYNC_RECEIVER) and has existed since the ISO subsystem was introduced (v2.6.0) through v4.4.0. The fix adds explicit buf-&amp;gt;len &amp;lt; sizeof(ts_hdr) and buf-&amp;gt;len &amp;lt; size…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-10658</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-10658</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-10658</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: zephyr, Ubuntu:18.04:LTS: zephyr, Ubuntu:20.04:LTS: zephyr, Ubuntu:22.04:LTS: zephyr, Ubuntu:24.04:LTS: zephyr, Ubuntu:25.10: zephyr, Ubuntu:26.04:LTS: zephyr&lt;/p&gt;
&lt;p&gt;bt_iso_recv() in subsys/bluetooth/host/iso.c pulled the ISO SDU header (4 bytes) or, when the timestamp flag is set, the timestamped SDU header (8 bytes) from the inbound HCI ISO Data buffer via net_buf_pull_mem() without first checking buf-&amp;gt;len. The upstream hci_iso() handler enforces buf-&amp;gt;len == the controller-declared ISO Data_Load length, so a malicious or buggy controller / adjacent BLE peer on an established CIS/BIS can present a first-fragment (BT_ISO_START) or single (BT_ISO_SINGLE) PDU shorter than the SDU header. Because net_buf_simple_pull_mem only guards length with __ASSERT_NO_MSG (compiled out when CONFIG_ASSERT is disabled, the production default), the pull underflows buf-&amp;gt;len (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-&amp;gt;data past valid data: the subsequent reads of hdr-&amp;gt;slen and hdr-&amp;gt;sn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-&amp;gt;rx, and a following CONT/END fragment&amp;#39;s net_buf_tailroom() guard underflows to a near-SIZE_MAX value, defeating the bounds check and causing net_buf_add_mem() to memcpy attacker-supplied fragment data far past the RX pool buffer (out-of-bounds write). The flaw affects ISO receive builds (CONFIG_BT_ISO_RX, selected by the default-off LE Audio options BT_ISO_PERIPHERAL/BT_ISO_CENTRAL/BT_ISO_SYNC_RECEIVER) and has existed since the ISO subsystem was introduced (v2.6.0) through v4.4.0. The fix adds explicit buf-&amp;gt;len &amp;lt; sizeof(ts_hdr) and buf-&amp;gt;len &amp;lt; size…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: zephyr, Ubuntu:18.04:LTS: zephyr, Ubuntu:20.04:LTS: zephyr, Ubuntu:22.04:LTS: zephyr, Ubuntu:24.04:LTS: zephyr, Ubuntu:25.10: zephyr, Ubuntu:26.04:LTS: zephyr&lt;/p&gt;
&lt;p&gt;bt_iso_recv() in subsys/bluetooth/host/iso.c pulled the ISO SDU header (4 bytes) or, when the timestamp flag is set, the timestamped SDU header (8 bytes) from the inbound HCI ISO Data buffer via net_buf_pull_mem() without first checking buf-&amp;gt;len. The upstream hci_iso() handler enforces buf-&amp;gt;len == the controller-declared ISO Data_Load length, so a malicious or buggy controller / adjacent BLE peer on an established CIS/BIS can present a first-fragment (BT_ISO_START) or single (BT_ISO_SINGLE) PDU shorter than the SDU header. Because net_buf_simple_pull_mem only guards length with __ASSERT_NO_MSG (compiled out when CONFIG_ASSERT is disabled, the production default), the pull underflows buf-&amp;gt;len (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-&amp;gt;data past valid data: the subsequent reads of hdr-&amp;gt;slen and hdr-&amp;gt;sn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-&amp;gt;rx, and a following CONT/END fragment&amp;#39;s net_buf_tailroom() guard underflows to a near-SIZE_MAX value, defeating the bounds check and causing net_buf_add_mem() to memcpy attacker-supplied fragment data far past the RX pool buffer (out-of-bounds write). The flaw affects ISO receive builds (CONFIG_BT_ISO_RX, selected by the default-off LE Audio options BT_ISO_PERIPHERAL/BT_ISO_CENTRAL/BT_ISO_SYNC_RECEIVER) and has existed since the ISO subsystem was introduced (v2.6.0) through v4.4.0. The fix adds explicit buf-&amp;gt;len &amp;lt; sizeof(ts_hdr) and buf-&amp;gt;len &amp;lt; size…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-10658</guid>
    </item>
  </channel>
</rss>
