CVE-2026-13480: Out-of-bounds read in LoRaWAN fragmented data block transport (FUOTA) downlink handler
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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using the LoRaWAN TS004 Fragmented Data Block Transport handler in loramac-node are exposed when they process crafted FUOTA downlinks. The vulnerable parsing is in frag_transport_package_callback().
What does an attacker need to do to trigger the out-of-bounds read?
The attacker needs to supply a malformed downlink sequence that first sets a fragment size through FRAG_SESSION_SETUP, then positions a matching-index DATA_FRAGMENT near the end of the actual decrypted payload. Mismatched-index DATA_FRAGMENT commands can be used as filler to advance the parser position before the final fragment is decoded.
How large can the unintended read be?
The fragment decoder reads ctx.frag_size bytes without checking the remaining payload length. The fragment size is attacker-controlled but capped by CONFIG_LORAWAN_FRAG_TRANSPORT_MAX_FRAG_SIZE, whose default is 232, allowing a read roughly that far beyond the RxPayload buffer.
What should be checked while applying a fix?
Review the FUOTA downlink parser for remaining-length validation before casting command bytes to frag_transport_setup_req and before passing fragment data to the decoder. The referenced Zephyr commit addresses this issue.