CVE-2026-18415 in Zephyr
Summary
by MITRE • 09/28/2026
ieee802154_send() in subsys/net/l2/ieee802154/ieee802154.c copies the outgoing packet into a single fixed 125-byte transmit buffer (tx_frame_buf_pool, sized IEEE802154_MTU). In builds with CONFIG_NET_L2_IEEE802154_FRAGMENT enabled (the default whenever CONFIG_NET_6LO is set), the branch taken when 6LoWPAN fragmentation is not required performed an unchecked net_buf_add_mem(frame_buf, pkt_buf->data, pkt_buf->len). The only guard was __ASSERT_NO_MSG() inside net_buf_simple_add(), which is compiled out without CONFIG_ASSERT, so an oversized packet silently overran the frame buffer.
The defect is not reachable from the radio: for NET_AF_INET6 packets ieee802154_6lo_encode_pkt() compares the whole packet length against IEEE802154_MTU and takes the fragmentation path when it does not fit, so every buffer copied on the unfragmented branch is within bounds. It is reachable through NET_AF_PACKET sockets bound to an 802.15.4 interface: for NET_SOCK_RAW the 6LoWPAN block is skipped entirely and for NET_SOCK_DGRAM it returns early on the address-family test, leaving no length validation anywhere on the transmit path (net_context_sendto() and net_if_tx() apply none, and pkt_buffer_length() does not clamp the allocation for this L2).
An application — or, in a CONFIG_USERSPACE build, an unprivileged application thread using the zsock_socket()/zsock_sendto() syscalls — can therefore drive a supervisor-mode out-of-bounds write of chosen bytes past the 125-byte pool buffer. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE of 128 bytes the overrun is bounded to roughly ll_hdr_len + 3 bytes; with CONFIG_NET_BUF_VARIABLE_DATA_SIZE a single storage buffer can be as large as CONFIG_NET_PKT_BUF_TX_DATA_POOL_SIZE, making the overrun far larger. The consequence is corruption of memory adjacent to the pool, with a crash or further compromise of kernel state as the practical impact.
The fix validates ll_hdr_len + net_pkt_get_len(pkt) + authtag_len against IEEE802154_MTU before any copy and adds a tailroom-checking copy_pkt_to_frame() helper that returns -EMSGSIZE instead of overrunning the buffer. The same change also linearizes the whole net_buf chain into one MAC frame, so packet storage boundaries no longer become frame boundaries on the wire.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability resides in the ieee802154_send function within the IEEE 802.15.4 network layer implementation of Zephyr RTOS, specifically affecting systems where CONFIG_NET_L2_IEEE802154_FRAGMENT is enabled alongside CONFIG_NET_6LO. The core technical flaw involves an unchecked memory copy operation when handling packets that do not require fragmentation. In this code path, the function attempts to copy outgoing packet data into a fixed-size transmit buffer of 125 bytes using net_buf_add_mem without performing prior length validation against the available space in the destination buffer. While the underlying helper function contains an assertion macro for debug builds, this check is disabled in production configurations where CONFIG_ASSERT is not set, allowing oversized packets to silently overwrite memory beyond the allocated buffer boundaries. This represents a classic out-of-bounds write vulnerability that compromises kernel integrity by corrupting adjacent heap or pool structures.
The exploitability of this flaw is contingent on specific network socket configurations and address families. While IPv6 traffic processed through standard 6LoWPAN encoding paths includes length checks that prevent overflow, raw sockets bound to an IEEE 802.15.4 interface bypass these protections entirely. Specifically, NET_SOCK_RAW sockets skip the fragmentation logic completely, and NET_SOCK_DGRAM sockets exit early due to address family mismatches in certain code branches. Consequently, neither net_context_sendto nor net_if_tx apply necessary length clamping for these socket types, leaving a direct path for an attacker to inject packets exceeding the 125-byte maximum transmission unit limit without triggering any validation errors.
An unprivileged application thread can leverage this vulnerability by utilizing standard Zephyr socket APIs such as zsock_socket and zsock_sendto in configurations that support user space execution. By sending raw or datagram packets larger than the MTU, an attacker can trigger a supervisor-mode out-of-bounds write. The extent of memory corruption depends on configuration parameters; with fixed data size settings, the overrun is limited to approximately three bytes plus header length, but variable data sizes allow for significantly larger overruns bounded only by the total packet buffer pool size. This arbitrary write capability enables potential denial of service through system crashes or more severe privilege escalation attacks by corrupting critical kernel state structures adjacent to the transmit buffer pool.
Industry standard classifications identify this issue as CWE-120, Buffer Copy without Checking Size of Input, and potentially CWE-787, Out-of-bounds Write, depending on whether memory corruption leads to code execution. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates initial access or privilege escalation via local exploitation, specifically mapping to T1059 Command and Scripting Interpreter if the corrupted state allows for arbitrary code execution primitives. The remediation strategy implemented in subsequent patches introduces rigorous length validation before any memory copy operation occurs. This includes verifying that the sum of link layer header length, packet data length, and authentication tag length does not exceed IEEE 802.15.4 MTU limits. Additionally, a new helper function ensures proper tailroom checking during buffer operations, returning an error code rather than proceeding with unsafe memory writes, thereby eliminating the possibility of out-of-bounds corruption in this network layer component.