{"id":"CVE-2026-13479","title":"Out-of-bounds read in LoRaWAN clock-sync AppTimeAns downlink handler","summary":"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 CLO…","severity":"low","cvss":3.1,"cvssVector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","cvssSource":"cna","cwe":["CWE-125"],"vendor":"zephyrproject","product":"zephyr","affected":["zephyr >= 3.3.0 < 4.3.2","zephyr >= 4.4.0 < 4.4.2"],"ssvc":{"exploitation":"none","automatable":"no","technicalImpact":"partial","timestamp":"2026-08-26T15:44:08.607894Z"},"published":"2026-08-26","updated":"2026-11-04","sourceUpdated":"2026-11-04T04:59:59.325Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-13479","references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/3d578067652b12993bca13fb8e07dc45d062d4a5","label":"Fix commit"},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2m6g-p3vx-p2fh","label":"GHSA-2m6g-p3vx-p2fh"}],"tags":["cve.org"],"epss":0.00226,"epssPercentile":0.13426,"ingestedAt":"2026-11-05T20:33:06.708Z","slug":"CVE-2026-13479","body":"## Overview\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\n## Affected\n\n- `zephyr >= 3.3.0 < 4.3.2`\n- `zephyr >= 4.4.0 < 4.4.2`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":17,"depthScoreParts":{"impact":17.1,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}