Skip to main content
VulnerabilityPublished Updated

CVE-2026-10658: zephyrproject zephyr · Memory-safety

Affects zephyrproject zephyrSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 7.1 High : upgrade to 4.6.0 soon.

Data as of 5 Nov 2026, 11:40 UTC

CVSS 3.1 base score
7.1High
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (zephyr)CVSS 3.17.1
EPSS
0.2% chance of exploitation in 30 days – higher than 20% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.6.0
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 22 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.

What to do

Upgrade zephyrproject zephyr to 4.6.0.

Affected software

ProductAffectedFixed in
zephyrprojectzephyrAffected
  • >=2.6.0 <4.6.0
Fixed in
  • 4.6.0
GitHubzephyrpkg:github/zephyrOther threatsAffected
  • >=2.6.0 <4.6.0
Fixed in
  • 4.6.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

The upstream fix involves adding explicit buffer length checks to drop malformed buffers before processing. If you cannot patch yet, avoid enabling ISO receive features (CONFIG_BT_ISO_RX) or the related LE Audio options (BT_ISO_PERIPHERAL, BT_ISO_CENTRAL, BT_ISO_SYNC_RECEIVER) if possible. Monitor vendor communications for official patches or updates.

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->len. The upstream hci_iso() handler enforces buf->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->len (uint16_t, e.g. 0 - 8 = 0xFFF8) and advances buf->data past valid data: the subsequent reads of hdr->slen and hdr->sn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso->rx, 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->len < sizeof(ts_hdr) and buf->len < sizeof(hdr) checks that drop the buffer before pulling.

References

Community reviews

Loading reviews…