{"id":"CVE-2026-75085","summary":"Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver","details":"The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame-\u003elength - IEEE802154_FCS_LENGTH without first checking that the radio-reported length could hold an FCS. pkt_len is a uint8_t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was __ASSERT_NO_MSG(pkt_len \u003c= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n).\n\nThe length originates in the ST link-layer receive-done metadata (p_metadata-\u003elength, stored by stm32wba_802154_receive_done()), and ultimately in the PHY header of a frame received over the air, so it is influenced by any attacker within radio range of the device. Reaching the underflow requires the vendor link layer to surface a frame shorter than the FCS with no error; the driver performed no validation of its own on that value.\n\nWhen the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame-\u003epsdu, pkt_len) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes). This reads roughly 128 bytes past the end of the radio receive buffer and copies that adjacent memory into a network packet that is submitted to the networking stack, giving an out-of-bounds read with a potential disclosure of adjacent RAM plus needless oversized packet allocation in the RX thread.\n\nThe fix rejects a frame whose reported length is smaller than IEEE802154_FCS_LENGTH before the subtraction, and replaces the compiled-out assertion with a runtime length check that drops oversized frames — matching the runtime check already present in drivers/ieee802154/ieee802154_nrf5.c.","aliases":["GHSA-w7pm-4r95-c9vr"],"modified":"2026-10-15T02:47:33.182135332Z","published":"2026-10-14T16:46:02.993Z","database_specific":{"cwe_ids":["CWE-125"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/75xxx/CVE-2026-75085.json","cna_assigner":"zephyr"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/75xxx/CVE-2026-75085.json"},{"type":"PACKAGE","url":"https://github.com/zephyrproject-rtos/zephyr"},{"type":"FIX","url":"https://github.com/zephyrproject-rtos/zephyr/commit/46f8af4f5ee472abc13b0291c44fdfe4ed879aaa"},{"type":"ADVISORY","url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-w7pm-4r95-c9vr"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-75085"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/zephyrproject-rtos/zephyr","events":[{"introduced":"3568e1b6d5cdd51a6b964a2a1d6d29200fea2056"},{"last_affected":"dccb09599635bdff17633fa7e9dab014b91dce90"}],"database_specific":{"source":"AFFECTED_FIELD","extracted_events":[{"introduced":"4.3.0"},{"last_affected":"4.4.2"}]}}],"versions":["v4.4.2","v4.4.2-rc1","v4.4.1","v4.4.1-rc1","v4.4.0","v4.4.0-rc3","v4.4.0-rc2","v4.4.0-rc1","v4.3.0"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-75085.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L"}]}