The LoRaWAN TS004 Fragmented Data Block Transport handler fragtransportpackagecallback() in subsys/lorawan/services/fragtransport.c parses downlink command bytes without validating that enough payload bytes remain before each access. The loop's only bound is rxpos < len; after consuming the one-byte command id the handler cast rxbuf + rxpos to a 10-byte struct fragtransportsetupreq, and for a DATAFRAGMENT command passed &rxbuf[rxpos] to the fragment decoder, which reads exactly ctx.fragsize bytes — with no remaining-length check in either case.

The fragment size is attacker-chosen in a preceding FRAGSESSIONSETUP command (ctx.fragsize = req->fragsize, capped at CONFIGLORAWANFRAGTRANSPORTMAXFRAGSIZE, default 232). rxbuf 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 DATAFRAGMENT filler commands (each advancing rxpos 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 fragsize 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.

The LoRaWAN Fragmented Data Block Transport service (subsys/lorawan/services/fragtransport.c) does not validate the fragment counter in a received DATAFRAGMENT command before forwarding it to the configured decoder. In fragtransportpackagecallback() the value fragcounter = hdr->fragindexn & 0x3FFF is taken directly from the downlink payload and passed to the decoder, which derives an array index and flash offset as fragcounter - 1. DataFragment fragments are 1-indexed, so a fragcounter of 0 underflows that arithmetic.

With the default Semtech/LoRaMAC-node decoder, this reaches FragDecoder.FragNbMissingIndex[fragCounter - 1] = 0; in FragDecoderProcess(), where fragCounter - 1 evaluates to -1 and writes a uint16t zero out of bounds, just before the array and into the adjacent MatrixM2B recovery-matrix state of the static decoder object (CWE-787). A companion write derives a wild flash offset, but that path is rejected by the flashareawrite() bounds check. The in-tree low-memory decoder (fragdec()) is not corrupted: its out-of-range bit-array and flash accesses are caught by sysbitarray and flasharea bounds checks.

The handler is the registered downlink callback for the fragmentation transport port, reachable whenever an active fragmentation session exists, so the triggering byte is attacker-influenceable LoRaWAN/FUOTA network input. Triggering it requires authenticated downlinks (LoRaWAN MAC session keys or a malicious/compromised network or FUOTA server) and an active fragmentation session. The impact is contained: corruption of decoder state and denial of the firmware-update (FUOTA) session rather than controllable memory corruption or code execution. The fix adds a transport-layer check that rejects fragcounter == 0, closing the defect for both decoder backends.