CVE-2026-13479

The LoRaWAN application-layer clock-synchronization service parses downlinks in clocksyncpackagecallback() (subsys/lorawan/services/clocksync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCKSYNCCMDAPPTIME (AppTimeAns) command the handler then reads a 4-byte time correction via sysgetle32() plus a 1-byte token without checking that 5 bytes remain in the receive buffer (len - rx_pos). A short or crafted AppTimeAns therefore reads up to 5 bytes past the end of the decrypted payload.

The payload (rxbuf/len) is the decrypted application frame delivered to the registered downlink callback (mcpsindication->Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the practical attacker is a malicious or compromised network/application server (the designated sender of AppTimeAns) or a party holding the session keys, rather than an arbitrary radio listener.

The over-read is bounded: the backing store is a fixed 255-byte static buffer, so the few stray bytes do not fault, and the read values (timecorrection, token) are used only internally and never transmitted, so there is no disclosure to the attacker and no crash. The sole effect is that a stale token matching ctx.reqtoken can apply a garbage timecorrection to the device's own clock offset (ctx.timeoffset), a minor integrity impact confined to the victim's time estimate. The fix adds an explicit length check that drops a too-short AppTimeAns. Note the sibling one-byte reads in the periodicity and force-resync handlers remain unguarded with the same negligible impact.