Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPosition within 802.15.4 radio range
-
DeliveryTransmit malformed sub-FCS frame
-
ExploitVendor link layer reports under-length to driver
-
Executionuint8_t length subtraction underflows to ~254
-
Persistnet_pkt_write reads past RX buffer
-
ImpactAdjacent RAM copied into network packet
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to be within IEEE 802.15.4 radio range of an STM32WBA-based device running the vulnerable ieee802154_stm32wba.c driver (AV:A - not remotely reachable). The specific prerequisite is that the ST vendor link layer (stm32wba_802154_receive_done / p_metadata->length) must surface a received frame whose reported length is smaller than IEEE802154_FCS_LENGTH (2) with no error, which drives the uint8_t underflow; the driver itself performed no validation. The out-of-bounds read occurs in the default production configuration precisely because CONFIG_ASSERT=n compiles the __ASSERT_NO_MSG bound check to nothing - so hardened builds with CONFIG_ASSERT=y are NOT exploitable (the assert would catch it). Limiting factors: no internet reachability, high attack complexity due to dependence on vendor-firmware behavior outside attacker control, read-only impact with no code execution, and confinement to STM32WBA + 802.15.4 deployments only. |
| Impact | This is a genuinely low-priority issue whose signals align consistently toward limited real-world risk, despite being a memory-safety flaw. The provided CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L, base 4.2) tells a coherent story: exploitation is possible without authentication (PR:N) but requires adjacency - the attacker must be within IEEE 802.15.4 radio range (AV:A), not reachable over the internet - and carries high attack complexity (AC:H) because the trigger depends on a condition outside the attacker's direct control: the ST vendor link layer must surface a frame shorter than the FCS without flagging an error. Impact is a bounded out-of-bounds read (C:L) disclosing ~128 bytes of adjacent RAM into a network packet, plus minor availability pressure (A:L) from oversized packet allocation; there is no integrity impact (I:N) and no code execution. No EPSS score was provided, so exploitation probability cannot be quantified. The vulnerability is NOT on the CISA KEV list and no public exploit or POC was identified - only the upstream patch commit and a GHSA advisory are referenced. There are no conflicting signals here: the adjacency requirement, high complexity, read-only low-confidentiality impact, and absence of exploitation evidence all point to a defense-in-depth hardening fix rather than an actively dangerous flaw. The one caveat worth verifying is the practical reachability of the trigger - whether the STM32WBA radio firmware can in fact be coaxed into reporting a sub-FCS length, which the advisory treats as the precondition for reaching the underflow. |
| Exploit ScenarioDerived | An attacker within IEEE 802.15.4 radio range of an STM32WBA-based Zephyr device transmits a malformed frame that causes the ST radio firmware to report a length of 0 or 1 (shorter than the 2-byte FCS). The uint8_t subtraction underflows to 254/255, and the RX thread reads ~128 bytes past the radio receive buffer into a network packet, disclosing adjacent RAM to the networking stack. No public POC exists at time of analysis; only the fixing commit and GHSA advisory are available. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
An out-of-bounds read in the Zephyr RTOS STM32WBA IEEE 802.15.4 driver (drivers/ieee802154/ieee802154_stm32wba.c) lets an attacker within radio range of an STM32WBA-based device copy roughly 128 bytes of adjacent RAM into a network packet delivered to the networking stack. The flaw affects Zephyr 4.3.0 through 4.4.2 in the default production configuration (CONFIG_ASSERT=n), where the only length bound is compiled out; builds with CONFIG_ASSERT=y are not exploitable because the assertion would fire first. Impact is limited to a read-only information disclosure and oversized packet allocation in the RX thread - no code execution and no internet-reachable path - and no public exploit identified at time of analysis, with CVSS scored 4.2 (AV:A/AC:H/PR:N/UI:N).
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed. The corrective commit is 46f8af4f5ee472abc13b0291c44fdfe4ed879aaa (https://github.com/zephyrproject-rtos/zephyr/commit/46f8af4f5ee472abc13b0291c44fdfe4ed879aaa), which adds a pre-subtraction check rejecting frames whose reported length is below IEEE802154_FCS_LENGTH and a runtime pkt_len > CONFIG_NET_BUF_DATA_SIZE check that drops oversized frames; apply or backport this patch rather than relying on any specific tag number. Until a patched Zephyr release is deployed, the most effective compensating control is to build with CONFIG_ASSERT=y, which restores the removed bound check and causes the malformed frame to be caught before the copy - the trade-off is that production assertions are undesirable in general and will panic the device on this input, converting a memory disclosure into a denial of service, and they add overhead. If the STM32WBA 802.15.4 radio function is not required, disable the driver entirely (drop the ieee802154_stm32wba driver and its RX thread from the build), which removes the attack surface at the cost of losing 802.15.4 connectivity. As a deployment-level control, keep STM32WBA devices physically outside radio range of untrusted transmitters; this is a weak mitigation since 802.15.4 range is easily extended with directional antennas or higher-gain hardware, but it does reduce exposure for isolated sensor deployments. Monitor the Zephyr advisory GHSA-w7pm-4r95-c9vr for the fixed release and note that hardened builds with CONFIG_ASSERT=y were never affected.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The issue is a CWE-125 out-of-bounds read rooted in unsigned integer underflow. The STM32WBA driver computes the received payload length as pkt_len = rx_frame->length - IEEE802154_FCS_LENGTH, where pkt_len is a uint8_t and IEEE802154_FCS_LENGTH is 2, without first verifying that the radio-reported frame length can actually accommodate a frame check sequence. A reported length of 0 or 1 wraps to 254 or 255. That length originates from the ST vendor link layer's receive-done metadata (p_metadata->length, set in stm32wba_802154_receive_done()) and ultimately from the PHY header of an over-the-air frame, so it is attacker-influenced by anyone transmitting within IEEE 802.15.4 radio range. The sole guard was __ASSERT_NO_MSG(pkt_len <= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing when CONFIG_ASSERT=n - the default production setting - so the check provides no protection in shipped builds. When the wrapped value reaches stm32wba_802154_rx_thread(), net_pkt_write(pkt, rx_frame->psdu, pkt_len) is called with ~254 bytes against a radio receive buffer sized for at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes), reading roughly 128 bytes past the buffer and copying adjacent RAM into a packet submitted upward. The fix mirrors the runtime check already used in drivers/ieee802154/ieee802154_nrf5.c: reject frames shorter than the FCS before subtraction, and replace the compiled-out assertion with a real runtime length check that drops oversized frames.
Know when Zephyr gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L
Adjacent radio access (AV:A), no auth (PR:N), AC:H because the trigger depends on vendor firmware reporting a sub-FCS length outside attacker control; bounded OOB read gives C:L/A:L, no integrity impact.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
An out-of-bounds write in the Zephyr RTOS DNS resolver (dns_unpack_name()) lets a crafted DNS response corrupt memory on
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
EUVD-2026-101342
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB