CVE-2026-13479
PoC nicheOut-of-bounds read in Zephyr RTOS LoRaWAN clock synchronization service
CVE-2026-13479 is an out-of-bounds read (CWE-125) in the LoRaWAN clock-synchronization service of the Zephyr RTOS, in clock_sync_package_callback() in subsys/lorawan/services/clock_sync.c. The CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) handler reads a 4-byte time correction and a 1-byte token without checking that 5 bytes remain in the decrypted downlink buffer, so a short or crafted AppTimeAns reads up to 5 bytes past the end of a fixed 255-byte static receive buffer. The over-read is bounded and causes no crash or information leak; the only impact is that a stale token match can apply a garbage time correction to the device's internal clock offset, a minor integrity issue confined to the victim's time estimate. Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the realistic attacker is a malicious or compromised LoRaWAN network/application server (the designated AppTimeAns sender) or any party holding the session keys, not an arbitrary radio listener. Only Zephyr-based LoRaWAN end devices with the clock-synchronization service enabled are affected; no in-the-wild exploitation is known (EPSS ~0.2%, not in CISA KEV), and the flaw is documented in public Zephyr security advisory GHSA-2m6g-p3vx-p2fh.
What to do: Update Zephyr to a release that includes the added length check in subsys/lorawan/services/clock_sync.c; the Zephyr advisory GHSA-2m6g-p3vx-p2fh lists the fixed versions/commits (exact version numbers are not present in this dataset). Until patched, disable the LoRaWAN clock-synchronization service if not needed or ensure only your trusted network server sends AppTimeAns. Note that sibling unguarded one-byte reads in the periodicity and force-resync handlers remain after this fix, with the same negligible impact.
| Zephyr Project Zephyr | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vendors
- zephyrproject
- Products
- zephyr
- Weakness
- CWE-125
- Vector
- CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
In the news0 stories
No ingested article mentions this CVE yet.