Description

The LoRaWAN application-layer clock-synchronization service parses downlinks in clock_sync_package_callback() (subsys/lorawan/services/clock_sync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command the handler then reads a 4-byte time correction via sys_get_le32() 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 (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication->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 (time_correction, 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.req_token can apply a garbage time_correction to the device's own clock offset (ctx.time_offset), 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-08-26T15:16:42.693Z",
  "pubdate": "2026-08-26T15:16:42.693Z",
  "executiveSummary": "A buffer over-read vulnerability exists in the LoRaWAN application-layer clock-synchronization service within the Zephyr RTOS codebase. The vulnerability originates in the clock_sync_package_callback function, where the parser fails to validate the remaining length of the decrypted application frame before reading multi-byte command parameters.\nThis flaw allows a malicious or compromised network/application server—or any entity possessing valid LoRaWAN session keys—to trigger an out-of-bounds read of up to 5 bytes beyond the actual decrypted payload buffer. Because the underlying memory structure is a fixed 255-byte static buffer, the over-read does not trigger a segmentation fault or crash, and the read data is never transmitted externally, preventing direct information disclosure.\nThe primary security impact is limited to a potential integrity compromise of the device's clock synchronization offset. An attacker can supply a malformed AppTimeAns command that, if it results in a token collision or valid-looking read, may update the internal time_offset with arbitrary or stale values. The risk is considered low, given the requirement for session key knowledge and the limited, localized impact on time estimation accuracy.",
  "technicalDetails": "The vulnerability resides in subsys/lorawan/services/clock_sync.c within the clock_sync_package_callback() function, which is responsible for processing incoming LoRaWAN application-layer clock synchronization packets. The root cause is a deficiency in input validation during the parsing of the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command.\nUpon receiving a frame on the designated clock-sync port, the service verifies the MAC integrity and decrypts the FRMPayload. Once the packet reaches the callback, the command loop verifies that the initial one-byte command identifier exists within the buffer boundaries. However, for the AppTimeAns command handler, the code proceeds to perform sequential reads—specifically a 4-byte time correction via sys_get_le32() and a subsequent 1-byte token—without confirming that the remaining buffer length (len - rx_pos) is sufficient to accommodate these 5 bytes.\nThe attack flow requires the adversary to act as, or compromise, a network or application server, or otherwise possess the session keys necessary to pass LoRaWAN frame decryption. The exploitation process follows these steps: 1) The attacker constructs a crafted LoRaWAN frame containing a short AppTimeAns payload. 2) The frame is transmitted to the device. 3) The device hardware and stack successfully decrypt the frame and pass it to the application-layer clock-sync service. 4) The service processes the one-byte command ID, which passes the existing boundary check. 5) The handler invokes sys_get_le32() and the subsequent token read, which accesses memory locations beyond the intended end of the decrypted payload (rx_buf).\nBecause the memory backing store is a fixed 255-byte static buffer, the out-of-bounds read does not cause a memory access violation or system crash. The data retrieved from the over-read is used to populate internal variables (time_correction and token) used for internal logic. If the stale token happens to match the expected ctx.req_token, the device will apply the garbage time_correction to its internal clock offset (ctx.time_offset). This results in a localized disruption of the device's temporal synchronization. The same lack of boundary checks is observed in the periodicity and force-resync handlers, confirming a systemic failure to validate packet length across the clock synchronization service."
}