https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 20:18:41 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-13479 <p>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.</p> <p>The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication-&gt;Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN&#39;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.</p> <p>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&#39;s own clock offset (ctx.time_offset), a minor integrity impact confined to the victim&#39;s time estimate. The f…</p> <p>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.</p> <p>The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication-&gt;Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN&#39;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.</p> <p>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&#39;s own clock offset (ctx.time_offset), a minor integrity impact confined to the victim&#39;s time estimate. The f…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-13479