CVE-2026-75085: Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver
The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154stm32wba.c computed the packet length of a received frame as pktlen = rxframe->length - IEEE802154FCSLENGTH without first checking that the radio-reported length could hold an FCS. pktlen is a uint8t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was ASSERTNOMSG(pktlen <= CONFIGNETBUFDATASIZE), which compiles to nothing in the default production configuration (CONFIGASSERT=n).
The length originates in the ST link-layer receive-done metadata (pmetadata->length, stored by stm32wba802154receivedone()), 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, stm32wba802154rxthread() calls netpktwrite(pkt, rxframe->psdu, pktlen) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154MAXPHYPACKETSIZE, 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 IEEE802154FCSLENGTH 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/ieee802154nrf5.c.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the STM32WBA IEEE 802.15.4 driver, reject received frames whose reported length is smaller than IEEE802154_FCS_LENGTH before subtracting the FCS length, and perform a runtime check that drops frames when pkt_len exceeds CONFIG_NET_BUF_DATA_SIZE; do not rely on the compiled-out __ASSERT_NO_MSG check.
Event History
Frequently Asked Questions
Which deployments are exposed to over-the-air exploitation?
Deployments using the STM32WBA IEEE 802.15.4 driver are exposed when an attacker is within radio range. The received-length value ultimately comes from the PHY header of a frame received over the air.
What must an attacker be able to send to trigger the condition?
The attacker needs the vendor link layer to report a received frame length of 0 or 1 while treating the frame as error-free. The driver performs no independent validation that the reported length is large enough to include the FCS.
Does the default production assertion configuration prevent the out-of-bounds read?
No. The only length bound was an assertion, and it is compiled out in the default production configuration when CONFIG_ASSERT=n. A zero- or one-byte reported length then wraps to approximately 254 or 255 bytes before the receive data is copied.