EUVD-2026-94229Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGet within 802.15.4 radio range
-
DeliverySend crafted short data frame
-
ExploitTrigger uint8_t payload_len underflow
-
ExecutionCCM reads/writes far past buffer
-
ImpactCorrupt buffer pool, fault device
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Integer underflow checks
|
| Exploitation Conditions | Exploitable ONLY when the target build enables the experimental CONFIG_NET_L2_IEEE802154_SECURITY option, selects a crypto backend via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME, and has an established IEEE 802.15.4 security session at a level other than IEEE802154_SECURITY_LEVEL_NONE (so authtag_len is non-zero). Given that configuration, no further prerequisites apply: any device in radio range can send one crafted data frame with a payload shorter than the authentication tag, with no association, key material, authentication, or user interaction required, because the frame is processed and the underflow triggered before tag verification. Limiting factors: the vulnerable feature is non-default and experimental, the attacker must be within 802.15.4 radio range (adjacent, not internet-remote), and builds with security disabled or at level NONE are not vulnerable because authtag_len is zero and no underflow occurs. |
| Impact | The vendor CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, 8.1 High) is internally consistent with the description: exploitation needs only radio-range (adjacent) access, is low-complexity (a single crafted short frame), and requires no privileges, authentication, association, or user interaction because the integer underflow occurs before the authentication tag is ever verified. No EPSS score was provided, the CVE is not on CISA KEV, and no public POC is referenced, so exploitation status is 'no public exploit identified at time of analysis' - real-world weaponization is currently unproven. SSVC-style reasoning: exploitation=none observed, automatable=yes (one fixed malformed frame works against any vulnerable node in range), technical impact=total for the affected node (crash/DoS). The critical mitigating signal NOT captured in the raw CVSS score is the deployment prerequisite: the flaw only exists when the EXPERIMENTAL CONFIG_NET_L2_IEEE802154_SECURITY option is enabled, a crypto device is configured, and an active security session at a level other than NONE is established - default and security-disabled builds are entirely unaffected. Net assessment: a genuinely high-severity, low-barrier DoS/memory-corruption bug for the narrow population of devices running the experimental 802.15.4 link-layer security stack, but far lower aggregate real-world risk than 8.1 implies because the vulnerable configuration is non-default and experimental. |
| Exploit ScenarioDerived | An attacker within IEEE 802.15.4 radio range of a Zephyr node running the experimental link-layer security feature transmits a single data frame whose payload is shorter than the configured authentication-tag length. The uint8_t subtraction underflows to a large payload_len, driving the CCM crypto operation to read and write up to roughly 240 bytes beyond the receive buffer into the adjacent network-buffer pool, corrupting other packets or allocator metadata and typically faulting the device. No prior association, key knowledge, or authentication is needed since the tag is only checked after the corruption occurs; no public exploit code is referenced at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
An integer underflow in Zephyr's IEEE 802.15.4 link-layer security receive path lets any attacker within radio range drive an out-of-bounds read and in-place write of up to roughly 240 bytes into the network buffer pool. When CONFIG_NET_L2_IEEE802154_SECURITY is enabled and a security session at a level other than IEEE802154_SECURITY_LEVEL_NONE is established, a single crafted data frame whose payload is shorter than the configured authentication tag makes payload_len wrap to as large as 255, so CCM decryption reads several hundred bytes past the end of the exactly-sized receive buffer - and this happens before the tag is ever verified, so no key material, association, authentication, or user interaction is needed (CVSS 8.1, AV:A/AC:L/PR:N/UI:N). The primary impact is memory corruption and denial of service rather than information disclosure, since the out-of-bounds bytes are not attacker-chosen and the frame is dropped when tag verification fails; no public exploit code was identified at time of analysis, and exposure is limited to builds that enable this non-default, experimental security feature.
RemediationAI
Apply the vendor fix, which is upstream commit 6d721de13a6026808f75578ecfee95a3592d5264 referenced in advisory GHSA-6x64-rwq6-j8x3 (https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6x64-rwq6-j8x3); note that this is a commit-level fix and a released patched version containing it was not independently confirmed, so verify the commit is present in the Zephyr release or branch you build from. Because the commit adds length guards on both the receive path in ieee802154_decipher_data_frame() and the transmit path in ieee802154_create_data_frame(), cherry-picking only the receive-side check leaves the reciprocal transmit-side defect unaddressed. If the patch cannot be deployed immediately, the most effective compensating control is to build without CONFIG_NET_L2_IEEE802154_SECURITY or to keep all sessions at IEEE802154_SECURITY_LEVEL_NONE, which sets authtag_len to zero and eliminates the underflow; the trade-off is that this removes IEEE 802.15.4 link-layer encryption and authentication entirely, exposing frame payloads to eavesdropping and forgery by nearby radios. Where link-layer security must remain enabled, restrict build/test fleets to trusted firmware images and avoid unified builds that mix this experimental option into low-trust device classes, and treat physical/RF exposure as the containment boundary, since any device in radio range can trigger the single short frame needed for exploitation. No vendor workaround short of the configuration change or the patch was identified.
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
Root cause is CWE-191 (integer underflow): in ieee802154_decipher_data_frame() in subsys/net/l2/ieee802154/ieee802154_frame.c, the code computes payload_len = net_pkt_get_len(pkt) - ll_hdr_len - authtag_len without first verifying that the received frame is at least ll_hdr_len + authtag_len bytes long. Because payload_len, ll_hdr_len and authtag_len are all uint8_t, a short payload subtracts below zero and wraps to a value up to 255 instead of faulting or being rejected. That wrapped length is passed unchanged into ieee802154_decrypt_auth() and then into the CCM operation as cipher_pkt.in_len/out_buf_max, while apkt->tag is set to frame + ll_hdr_len + payload_len. Since the receive net_buf is allocated to exactly the frame length reported by the radio driver, the crypto layer reads and writes beyond the buffer, overwriting adjacent buffers or allocator metadata in the network-buffer pool. Frame validation in ieee802154_validate_frame() does not stop this: a data frame with a one-byte payload is accepted, and the authentication tag is only checked after decryption has already occurred. The vulnerable state requires a crypto backend selected via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME and an active session at a security level other than NONE; when security is disabled or the level is NONE, authtag_len is zero and no underflow can occur. The upstream fix rejects frames shorter than ll_hdr_len + authtag_len before the subtraction in the receive path and adds the matching guard in ieee802154_create_data_frame() on the transmit side; the affected CPE cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:* indicates the wildcard applies across tracked Zephyr versions.
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:L/PR:N/UI:N/S:U/C:N/I:H/A:H
A single crafted frame from any in-range device processed before the tag check gives AV:A/AC:L/PR:N/UI:N; the OOB write corrupts adjacent memory (I:H) and faults the node (A:H); leaked content is not attacker-chosen so C:N.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
ieee802154_decipher_data_frame() in subsys/net/l2/ieee802154/ieee802154_frame.c computed payload_len = net_pkt_get_len(pkt) - ll_hdr_len - authtag_len without first checking that the received frame is at least ll_hdr_len + authtag_len bytes long. All three variables are uint8_t, so a frame whose payload is shorter than the configured authentication tag makes the subtraction wrap around to a large value (up to 255).
The wrapped length is passed unchanged to ieee802154_decrypt_auth() and on to the CCM operation as cipher_pkt.in_len/out_buf_max, with apkt->tag pointing at frame + ll_hdr_len + payload_len. Because the receive buffer is allocated to the exact length of the frame received from the radio driver, the crypto layer then reads several hundred bytes past the end of the packet buffer and writes the same number of decrypted bytes back over it in place. The frame's authentication tag is only verified after this processing has taken place, so no key material, association or prior authentication is needed - a single crafted short frame from any device in radio range is sufficient. Frame validation in ieee802154_validate_frame() does not prevent it: a data frame is accepted with a one-byte payload.
The result is an out-of-bounds read and an out-of-bounds write of up to roughly 240 bytes into the adjacent network-buffer pool, corrupting other packets or allocator metadata and typically faulting the target. The out-of-bounds content is not attacker-chosen (it is ciphertext XOR keystream over out-of-bounds memory) and the frame is dropped when tag verification fails, so the primary impact is memory corruption and denial of service rather than information disclosure.
Exposure is limited to configurations that enable the experimental CONFIG_NET_L2_IEEE802154_SECURITY option, select a crypto device via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME, and have established a security session with a level other than IEEE802154_SECURITY_LEVEL_NONE; with security disabled or at level NONE the tag length is zero and no underflow occurs. The fix rejects frames shorter than ll_hdr_len + authtag_len before the subtraction, and adds the matching guard on the transmit side in ieee802154_create_data_frame().
Technical POC Analysis
CWE-191 (integer underflow/wraparound), chained to CWE-787 (out-of-bounds write).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Zephyr RTOS devices using IEEE 802.15.4 link-layer security are exposed to a radio-adjacent, unauthenticated memory-corruption and denial-of-service issue. An attacker within radio range can crash or destabilize affected devices without keys or user interaction, disrupting IoT/OT operations that depend on 802.15.4 mesh or sensor networks; no public exploit identified at time of analysis. Leadership should care because remediation is available, but the affected population may be widely deployed and hard to update while exploitation does not require public exploit code to pose operational risk.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
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.
Integer overflow occurs when an arithmetic operation produces a result that exceeds the maximum value a given integer type can store.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
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
Exploit-DB