Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-08-26T15:16:42.830Z",
  "pubdate": "2026-08-26T15:16:42.830Z",
  "executiveSummary": "The LoRaWAN TS004 Fragmented Data Block Transport service in subsys/lorawan/services/frag_transport.c contains a critical boundary validation flaw during the parsing of downlink commands.\nThe vulnerability is an out-of-bounds (OOB) memory read occurring because the frag_transport_package_callback() function fails to verify that sufficient buffer space remains within the decrypted payload before accessing structured data or invoking the fragment decoder.\nSuccessful exploitation requires the attacker to possess the target device's session keys to pass MIC (Message Integrity Check) and FRMPayload decryption, effectively restricting the threat to authorized network participants or those who have compromised session-level security.\nThe impact is a bounded out-of-bounds memory read, allowing an attacker to pull adjacent static memory from the MacCtx.RxPayload buffer into internal decoder buffers and subsequently into the FUOTA flash image.\nWhile the lack of a direct uplink disclosure channel limits the immediate confidentiality impact, the exposure of static memory contents into persistent flash storage constitutes a significant information leakage risk.\nThe vulnerability is exacerbated by the reliance on flawed bounds checking within the loop iteration logic, which can be bypassed using crafted, attacker-controlled fragment indices.",
  "technicalDetails": "The vulnerability resides in the frag_transport_package_callback() function within subsys/lorawan/services/frag_transport.c, which handles Fragmented Data Block Transport (TS004) downlinks.\nThe root cause is an improper bounds check in the parsing loop, which relies solely on 'rx_pos < len' without accounting for the specific size requirements of the parsed structures or the subsequent fragment decoding operation.\nWhen processing a FRAG_SESSION_SETUP command, the handler casts a pointer within the static 255-byte MacCtx.RxPayload buffer (rx_buf + rx_pos) directly to a 10-byte 'frag_transport_setup_req' structure without verifying if 10 bytes remain in the payload.\nFurthermore, when a DATA_FRAGMENT command is processed, the handler invokes the fragment decoder using 'ctx.frag_size', which is determined by a preceding session setup. This value can be as large as the configured maximum, typically 232 bytes.\nThe attack flow involves an attacker sending a sequence of malformed downlink packets. By injecting filler DATA_FRAGMENT commands that advance the 'rx_pos' index by three bytes each, the attacker can manipulate the internal offset of the parser.\nBy strategically padding the downlink payload and appending a valid, matching-index fragment at the end, the attacker forces the decoder to read past the end of the 255-byte 'rx_buf'.\nBecause the decoder accesses memory relative to the end of the legitimate decrypted payload, it performs an out-of-bounds read, consuming static memory located adjacent to 'rx_buf' in the memory map.\nThe stolen data is then incorporated into the FUOTA flash image process, potentially exposing sensitive static variables or memory contents, depending on the memory layout of the specific MCU implementation.\nSince the LoRaWAN implementation typically operates in a flat-memory space, this over-read is unlikely to trigger a segmentation fault or device crash, allowing for silent, stealthy exploitation.\nAccess to this vulnerability is conditional; it is unreachable without valid session keys, as the LoRaWAN stack enforces cryptographic verification via MIC and payload decryption before the command handler is ever invoked.\nThis vulnerability effectively turns the FUOTA mechanism into an unintended data extraction vector for memory regions adjacent to the MAC-layer buffers."
}