{"id":"CVE-2026-10658","aliases":["EUVD-2026-38410","GHSA-26g8-rmpf-j6cw","UBUNTU-CVE-2026-10658"],"status":"published","title":"Out-of-bounds access in Bluetooth ISO receive (`bt_iso_recv`) due to missing SDU-header length validation","description":"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-\u003elen. The upstream hci_iso() handler enforces buf-\u003elen == 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-\u003elen (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-\u003edata past valid data: the subsequent reads of hdr-\u003eslen and hdr-\u003esn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-\u003erx, and a following CONT/END fragment'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-\u003elen \u003c sizeof(ts_hdr) and buf-\u003elen \u003c sizeof(hdr) checks that drop the buffer before pulling.","severity":{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00282,"percentile":0.20886,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-125","CWE-787"],"published":"2026-06-22T23:58:47Z","modified":"2026-11-04T04:58:35Z","affected":[{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1","3.1.2-1build1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1build1","3.1.2-1build2"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1build3"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1build3"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1.1","3.1.2-1.1build1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1.1build1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-4"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1.1build1","3.1.2-4"]}],"products":[{"vendor":"zephyrproject","product":"zephyr"},{"vendor":"zephyrproject-rtos","product":"zephyr"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/756b16b64317defefad36fc994316cf96e418708","tags":["patch","fix"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-26g8-rmpf-j6cw","tags":["Issue Tracking","Patch","Vendor Advisory","advisory","report"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/10xxx/CVE-2026-10658.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-10658","tags":["advisory"]},{"url":"https://github.com/zephyrproject-rtos/zephyr","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-10658","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-10658","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-10658","title":"Out-of-bounds access in Bluetooth ISO receive (`bt_iso_recv`) due to missing SDU-header length validation","description":"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-\u003elen. The upstream hci_iso() handler enforces buf-\u003elen == 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-\u003elen (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-\u003edata past valid data: the subsequent reads of hdr-\u003eslen and hdr-\u003esn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-\u003erx, and a following CONT/END fragment'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-\u003elen \u003c sizeof(ts_hdr) and buf-\u003elen \u003c sizeof(hdr) checks that drop the buffer before pulling.","status":"published","published":"2026-06-22T23:58:47.022Z","modified":"2026-11-04T04:58:35.485Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-787","CWE-125"],"updated_at":"2026-11-04T05:21:48.223566Z"}],"euvd":[{"id":"EUVD-2026-38410","description":"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-\u003elen. The upstream hci_iso() handler enforces buf-\u003elen == 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-\u003elen (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-\u003edata past valid data: the subsequent reads of hdr-\u003eslen and hdr-\u003esn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-\u003erx, and a following CONT/END fragment'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-\u003elen \u003c sizeof(ts_hdr) and buf-\u003elen \u003c sizeof(hdr) checks that drop the buffer before pulling.","status":"published","published":"2026-06-22T23:58:47Z","modified":"2026-11-04T04:58:35Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-04T07:00:56.720215Z"}],"nvd":[{"id":"CVE-2026-10658","description":"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-\u003elen. The upstream hci_iso() handler enforces buf-\u003elen == 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-\u003elen (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-\u003edata past valid data: the subsequent reads of hdr-\u003eslen and hdr-\u003esn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-\u003erx, and a following CONT/END fragment'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-\u003elen \u003c sizeof(ts_hdr) and buf-\u003elen \u003c sizeof(hdr) checks that drop the buffer before pulling.","status":"published","published":"2026-06-23T01:16:26.867Z","modified":"2026-11-04T05:18:24.41Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-787","CWE-125"],"updated_at":"2026-11-04T06:53:16.37612Z"}],"osv":[{"id":"CVE-2026-10658","title":"Out-of-bounds access in Bluetooth ISO receive (`bt_iso_recv`) due to missing SDU-header length validation","description":"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-\u003elen. The upstream hci_iso() handler enforces buf-\u003elen == 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-\u003elen (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-\u003edata past valid data: the subsequent reads of hdr-\u003eslen and hdr-\u003esn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-\u003erx, and a following CONT/END fragment'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-\u003elen \u003c sizeof(ts_hdr) and buf-\u003elen \u003c sizeof(hdr) checks that drop the buffer before pulling.","status":"published","published":"2026-06-22T23:58:47.022Z","modified":"2026-11-05T08:04:21.820120586Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"cwes":["CWE-787"],"updated_at":"2026-11-05T09:08:14.330889Z"},{"id":"UBUNTU-CVE-2026-10658","description":"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-\u003elen. The upstream hci_iso() handler enforces buf-\u003elen == 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-\u003elen (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf-\u003edata past valid data: the subsequent reads of hdr-\u003eslen and hdr-\u003esn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso-\u003erx, and a following CONT/END fragment'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-\u003elen \u003c sizeof(ts_hdr) and buf-\u003elen \u003c sizeof(hdr) checks that drop the buffer before pulling.","status":"published","published":"2026-06-23T01:16:00Z","modified":"2026-10-17T12:58:01.105424449Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T16:55:59.130573Z"}]}}