CVE-2026-75085Medium· 4.2▾ SunlitThe 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->length - IEEE802154_FCS_LENGTH without first checking that the radio-reported length coul…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 23.1 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Oct 16.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.2%
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->length - 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 <= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n).
The length originates in the ST link-layer receive-done metadata (p_metadata->length, 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.
When the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame->psdu, 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.
The 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.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-18748Low· 3.5Out-of-bounds read in Bluetooth Classic A2DP codec information element handling
CVE-2026-10680High· 7.6Out-of-bounds access in Zephyr BR/EDR L2CAP configuration request handling via `uint16_t` length underflow
CVE-2026-10672High· 8.2Unterminated URI buffer causes out-of-bounds read in LwM2M firmware pull (Package URI)
CVE-2026-10673High· 8.3Out-of-bounds write in ADIN2111/ADIN1110 OA SPI Ethernet RX frame reassembly
CVE-2026-10657Low· 3.7Out-of-bounds read in Zephyr DNS resolver mDNS suffix check (memcmp past string NUL)
CVE-2026-19673High· 7.1ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr