{"id":"CVE-2026-75085","aliases":["EUVD-2026-101342","GHSA-w7pm-4r95-c9vr"],"status":"published","title":"Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver","description":"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.","severity":{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00205,"percentile":0.1065,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-125"],"published":"2026-10-14T16:46:02Z","modified":"2026-11-04T05:19:00Z","products":[{"vendor":"zephyrproject","product":"zephyr"},{"vendor":"zephyrproject-rtos","product":"zephyr"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/46f8af4f5ee472abc13b0291c44fdfe4ed879aaa","tags":["patch","fix"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-w7pm-4r95-c9vr","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/75xxx/CVE-2026-75085.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-75085","tags":["advisory"]},{"url":"https://github.com/zephyrproject-rtos/zephyr","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-75085","title":"Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver","description":"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.","status":"published","published":"2026-10-14T16:46:02.993Z","modified":"2026-11-04T05:01:08.079Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-125"],"updated_at":"2026-11-04T06:53:01.479776Z"}],"euvd":[{"id":"EUVD-2026-101342","description":"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.","status":"published","published":"2026-10-14T16:46:02Z","modified":"2026-11-04T05:01:08Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L","level":"medium"}],"updated_at":"2026-11-04T07:00:56.104537Z"}],"nvd":[{"id":"CVE-2026-75085","description":"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.","status":"published","published":"2026-10-14T17:19:10.607Z","modified":"2026-11-04T05:19:00.83Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L","level":"medium","assessor":"secondary"}],"cwes":["CWE-125"],"updated_at":"2026-11-04T06:53:25.251493Z"}],"osv":[{"id":"CVE-2026-75085","title":"Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver","description":"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.","status":"published","published":"2026-10-14T16:46:02.993Z","modified":"2026-11-05T13:08:36.946602484Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L","level":"medium"}],"cwes":["CWE-125"],"updated_at":"2026-11-05T13:30:00.949926Z"}]}}