Description

The LoRaWAN Fragmented Data Block Transport service (subsys/lorawan/services/frag_transport.c) does not validate the fragment counter in a received DATA_FRAGMENT command before forwarding it to the configured decoder. In frag_transport_package_callback() the value frag_counter = hdr->frag_index_n & 0x3FFF is taken directly from the downlink payload and passed to the decoder, which derives an array index and flash offset as frag_counter - 1. DataFragment fragments are 1-indexed, so a frag_counter 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 uint16_t 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 flash_area_write() bounds check. The in-tree low-memory decoder (frag_dec()) is not corrupted: its out-of-range bit-array and flash accesses are caught by sys_bitarray_ and flash_area_ 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 frag_counter == 0, closing the defect for both decoder backends.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-08-14T18:17:21.697Z",
  "pubdate": "2026-08-14T18:17:21.697Z",
  "executiveSummary": "A vulnerability exists in the LoRaWAN Fragmented Data Block Transport service, specifically within subsys/lorawan/services/frag_transport.c, categorized as an out-of-bounds write (CWE-787). The flaw arises from a lack of validation regarding the fragment counter in a received DATA_FRAGMENT command before it is passed to the configured decoder. When a crafted downlink payload provides an invalid fragment index, an arithmetic underflow occurs during array indexing and flash offset calculation.\nThe impact of this vulnerability is strictly contained to the corruption of the static decoder object state and a resulting denial of service for the ongoing firmware-update (FUOTA) session, rather than arbitrary memory corruption or remote code execution. Exploitation requires authenticated LoRaWAN downlinks, meaning an attacker must possess valid LoRaWAN MAC session keys or operate a malicious or compromised network or FUOTA server, alongside an active fragmentation session.\nAffected systems include implementations utilizing the LoRaWAN Fragmented Data Block Transport service with the default Semtech/LoRaMAC-node decoder. Risk implications are limited to the disruption of firmware over-the-air update capabilities on target devices. Remediation requires implementing a transport-layer bounds check to explicitly reject zero-valued fragment counters prior to decoder processing.",
  "technicalDetails": "The root cause of the vulnerability resides in subsys/lorawan/services/frag_transport.c, specifically within the frag_transport_package_callback() function. The service extracts the fragment counter directly from the downlink payload using the operation frag_counter = hdr->frag_index_n & 0x3FFF without validating its range against the expected 1-indexed specification for DataFragment fragments.\nBecause fragments are defined as 1-indexed, passing a frag_counter value of 0 causes an arithmetic underflow when the downstream decoder derives an array index and flash offset using frag_counter - 1. When utilizing the default Semtech/LoRaMAC-node decoder, this unvalidated value reaches the statement FragDecoder.FragNbMissingIndex[fragCounter - 1] = 0; inside FragDecoderProcess(). Here, fragCounter - 1 evaluates to -1, resulting in a uint16_t zero write out of bounds directly preceding the array and corrupting the adjacent MatrixM2B recovery-matrix state within the static decoder object.\nA companion write attempts to derive a wild flash offset, but this specific exploitation path is safely blocked by subsequent bounds checks in flash_area_write(). The in-tree low-memory decoder (frag_dec()) is inherently protected against this vector because its out-of-range bit-array and flash accesses are intercepted and caught by sys_bitarray_ and flash_area_ bounds checks.\nThe attack flow requires an adversary to leverage authenticated downlinks via valid LoRaWAN MAC session keys or a compromised network or FUOTA server while an active fragmentation session is established. The vulnerable handler is registered as the downlink callback for the fragmentation transport port, making it fully reachable whenever an active fragmentation session exists. Upon receiving the malicious DATA_FRAGMENT command containing the attacker-influenced zero-index byte, the service forwards the unvalidated integer directly to the decoder backend, triggering the out-of-bounds write and terminating the FUOTA process."
}