CVE-2026-12630 in Zephyr
Summary
by MITRE • 08/17/2026
Zephyr's 6LoWPAN IP Header Compression (IPHC) uncompression code contains an out-of-bounds read in get_ihpc_inlined_size() (subsys/net/ip/6lo.c). The destination inline size is looked up in da_inline_size_table, which has 13 entries, using an index built from the M, DAC and DAM bits of the received IPHC dispatch word (iphc & NET_6LO_IPHC_DA_MASK, a 4-bit value of 0-15). The reserved combinations 13, 14 and 15 are not bounds-checked and read past the end of the table.
The iphc word is taken directly from the received frame, and get_ihpc_inlined_size() is reached on every inbound 6LoWPAN frame via net_6lo_uncompress() from the 802.15.4 receive path (subsys/net/l2/ieee802154/ieee802154_6lo.c and ieee802154_6lo_fragment.c). An unauthenticated attacker on the radio/adjacent link can therefore craft a frame whose destination addressing-mode nibble selects an out-of-range index, with no privileges or user interaction.
The out-of-bounds value becomes the computed inline_size, which then drives header reconstruction before the buffer-length check: it is used to dereference *(pkt->buffer->data + sizeof(iphc) + inline_size) and to compute a size_t diff that can underflow, leading to a further out-of-bounds read of the packet buffer and malformed uncompression. The practical impact is a radio-triggerable out-of-bounds read / denial-of-service on the receiver; the leaked byte is not returned to the attacker. The fix rejects any destination index beyond the table, aborting processing of the malformed frame.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability resides within the Zephyr RTOS implementation of 6LoWPAN IP Header Compression (IPHC) uncompression logic, specifically in the function get_ihpc_inlined_size located in subsys/net/ip/6lo.c. This component is responsible for reconstructing IPv6 headers from compressed packets received over IEEE 802.15.4 wireless networks. The core technical flaw involves an improper validation of input data derived directly from network frames, leading to an out-of-bounds read condition that can be triggered by unauthenticated attackers operating on the adjacent radio link.
The mechanism of exploitation centers on the destination addressing mode bits within the IPHC dispatch word. When a 6LoWPAN frame is received, the system extracts specific bits known as M, DAC, and DAM to determine how the destination address should be handled during decompression. These bits form a four-bit index used to look up values in da_inline_size_table, which contains only thirteen valid entries indexed from zero to twelve. However, the code fails to perform bounds checking for indices corresponding to reserved combinations ten through fifteen. Consequently, when an attacker crafts a frame with these specific bit patterns, the lookup operation accesses memory locations beyond the allocated boundary of the table.
This out-of-bounds read occurs early in the processing pipeline via net_6lo_uncompress(), which is invoked from the IEEE 802.154 receive path including ieee802154_6lo.c and ieee802154_6lo_fragment.c. Because this code executes for every inbound frame, it presents a high-frequency attack surface accessible to any device within radio range without requiring authentication or user interaction. The invalid index results in an incorrect inline_size value being computed, which subsequently drives the header reconstruction process before standard buffer-length checks are applied.
The consequences of this flaw extend beyond simple memory leakage. The erroneous inline_size is used to calculate a pointer offset by adding it to sizeof(iphc) and dereferencing *(pkt->buffer->data + ...). Furthermore, this value participates in arithmetic operations that compute a size_t difference. Due to the nature of unsigned integer arithmetic, an excessively large index can cause an underflow when subtracted from smaller values or used in length calculations. This leads to further out-of-bounds reads within the packet buffer and results in malformed uncompression logic. While the immediate practical impact is primarily a denial of service due to potential crashes or undefined behavior during processing, the memory access also constitutes information disclosure as it leaks adjacent kernel memory contents.
From a classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-190 Integer Overflow or Wraparound. In terms of tactical mapping within the MITRE ATT&CK framework for IoT environments, this represents an exploitation vector that leverages network-based attacks against constrained devices, specifically targeting protocol implementation flaws in low-power wireless networks. The attacker does not need to compromise a device beforehand but can directly impact system stability through malformed packet injection.
Mitigation strategies must focus on strict input validation at the earliest possible stage of frame processing. Developers should implement explicit bounds checking for all indices derived from network headers before they are used as array subscripts or arithmetic operands. Specifically, any index resulting from IPHC dispatch word parsing must be validated against the maximum valid size of associated lookup tables prior to access. Additionally, implementing defensive programming practices such as using safe integer libraries that detect overflow and underflow conditions can prevent secondary exploitation vectors arising from incorrect size calculations. For users unable to immediately patch their systems, network-level filtering or intrusion detection signatures targeting malformed 6LoWPAN frames with reserved addressing modes may provide temporary relief by dropping suspicious traffic before it reaches the vulnerable kernel code.