CVE-2026-13480 in Zephyr
Summary
by MITRE • 08/26/2026
The LoRaWAN TS004 Fragmented Data Block Transport handler frag_transport_package_callback() in subsys/lorawan/services/frag_transport.c parses downlink command bytes without validating that enough payload bytes remain before each access. The loop's only bound is rx_pos < len; after consuming the one-byte command id the handler cast rx_buf + rx_pos to a 10-byte struct frag_transport_setup_req, and for a DATA_FRAGMENT command passed &rx_buf[rx_pos] to the fragment decoder, which reads exactly ctx.frag_size bytes — with no remaining-length check in either case.
The fragment size is attacker-chosen in a preceding FRAG_SESSION_SETUP command (ctx.frag_size = req->frag_size, capped at CONFIG_LORAWAN_FRAG_TRANSPORT_MAX_FRAG_SIZE, default 232). rx_buf aliases the 255-byte static MacCtx.RxPayload buffer in the loramac-node MAC layer, while len is the actual decrypted payload length. By padding a downlink with mismatched-index DATA_FRAGMENT filler commands (each advancing rx_pos by three bytes without producing an answer) and appending one matching-index fragment near the end of the payload, an attacker can make the decoder read up to roughly frag_size bytes past the end of RxPayload, copying adjacent static memory into the decoder buffers and the FUOTA flash image.
The handler runs only on downlinks that have already passed the LoRaWAN frame MIC and FRMPayload decryption, so the defect is reachable only by a party holding the device's session keys (the FUOTA server or an attacker who has compromised those keys). The out-of-bounds bytes are never returned to the sender — the only uplink emitted is a status answer carrying fragment counts — so there is no direct disclosure channel, and on typical flat-memory LoRaWAN MCUs the over-read stays within mapped memory, making a crash unlikely. The impact is therefore a bounded out-of-bounds read with limited confidentiality consequence and no write or control-flow primitive. The fix adds remaining-length guards before each access.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in the LoRaWAN TS004 Fragmented Data Block Transport handler, specifically within the frag_transport_package_callback function located in subsys/lorawan/services/frag_transport.c, represents a critical input validation failure that leads to out-of-bounds memory reads. This flaw stems from an insufficient check of buffer boundaries before accessing payload data structures. The core issue lies in the loop condition which only verifies that rx_pos is less than len, but fails to ensure there are sufficient remaining bytes in the buffer for subsequent structural casts and array accesses. Specifically, after consuming a single byte for the command identifier, the handler blindly casts the pointer at rx_buf plus rx_pos into a ten-byte structure representing frag_transport_setup_req without verifying if that many bytes exist from the current position to the end of the payload. Furthermore, when processing DATA_FRAGMENT commands, the code passes &rx_buf[rx_pos] directly to the fragment decoder, which then proceeds to read exactly ctx.frag_size bytes. There is no intermediate check to confirm that rx_pos plus frag_size does not exceed the total length len or the static buffer size, creating a classic off-by-one or out-of-bounds read scenario depending on the specific payload construction.
The operational impact of this vulnerability is facilitated by an attacker-controlled variable derived from a preceding FRAG_SESSION_SETUP command. The ctx.frag_size field, which dictates how many bytes the decoder will attempt to read, is set based on user input but capped at CONFIG_LORAWAN_FRAG_TRANSPORT_MAX_FRAG_SIZE, with a default value of 232 bytes. This buffer size is significant relative to the static MacCtx.RxPayload buffer in the loramac-node MAC layer, which has a fixed capacity of only 255 bytes. By carefully crafting downlink packets that include mismatched-index DATA_FRAGMENT filler commands, an attacker can manipulate rx_pos to advance by three bytes per command without triggering immediate errors or responses. This manipulation allows the attacker to position the read pointer near the end of the valid payload range and then append a matching-index fragment at the very tail. Consequently, when the decoder executes its read operation using the large ctx.frag_size value, it accesses memory locations beyond the allocated RxPayload buffer boundary. These out-of-bounds reads copy adjacent static memory contents into the decoder buffers and potentially into FUOTA flash image structures, leading to data corruption or leakage of sensitive internal state information stored in nearby memory regions.
From a security classification perspective, this vulnerability aligns with CWE-125: Out-of-bounds Read, as it involves reading beyond the intended buffer boundary due to improper validation of input lengths. In terms of attack vectors and techniques, this flaw can be mapped to ATT&CK Tactic TA0043: Impact or potentially TA0009: Collection if the leaked data is sensitive enough for further exploitation, though primarily it represents a confidentiality risk through memory disclosure rather than direct system compromise. The reachability of this defect is constrained by the fact that the handler processes only downlinks that have successfully passed LoRaWAN frame MIC verification and FRMPayload decryption. This means the vulnerability can only be exploited by an entity possessing the device's session keys, such as a legitimate FUOTA server or an attacker who has previously compromised those cryptographic credentials. Therefore, while the technical flaw is severe in isolation, its practical exploitability requires a higher level of initial compromise compared to vulnerabilities exploitable over unauthenticated channels.
The consequences of this out-of-bounds read are bounded and limited in scope on typical hardware architectures used for LoRaWAN devices. Because the RxPayload buffer aliases static memory within the MCU's address space, reading beyond its end typically remains within mapped physical or virtual memory boundaries, preventing immediate segmentation faults or system crashes that would result from accessing unmapped pages. Additionally, the over-read data is not directly returned to the sender in a way that creates an easy side-channel for exfiltration; the only uplink response generated by this handler is a status answer containing fragment counts rather than the raw memory contents read during processing. There are no write primitives or control-flow hijacking vectors associated with this specific flaw, meaning it does not allow for arbitrary code execution or privilege escalation directly. However, the potential leakage of adjacent static data could reveal internal state variables, cryptographic nonces, or other sensitive information that might aid in further attacks if combined with other vulnerabilities.
To mitigate this vulnerability, developers must implement rigorous bounds checking before any memory access operation within the fragment transport handler. The fix involves adding explicit remaining-length guards prior to casting pointers into structures and invoking the fragment decoder. Specifically, the code should verify that len minus rx_pos is greater than or equal to the size of the frag_transport_setup_req structure (ten bytes) before performing the cast. Similarly, for DATA_FRAGMENT commands, a check must ensure that len minus rx_pos is at least ctx.frag_size before passing &rx_buf[rx_pos] to the decoder. These validations should be performed immediately after parsing the command ID and updating rx_pos accordingly. By enforcing these constraints, the system ensures that all memory accesses remain within the allocated bounds of the RxPayload buffer, effectively neutralizing the out-of-bounds read condition. Regular code audits focusing on array indexing and pointer arithmetic in embedded C applications are recommended to prevent similar issues across other subsystems handling network payloads.