CVE-2026-10655: Zephyr SNTP Race Condition DoS Vulnerability

Technical summary

CVE-2026-10655 is a use-after-free vulnerability in Zephyr's asynchronous SNTP client (sntp_close_async in subsys/net/lib/sntp/sntp.c). The vulnerability arises from unsynchronized socket closure across thread boundaries. The socket service thread maintains an active k_poll_event on a net_context's recv_q while blocked in k_poll. When sntp_close_async is invoked from a different thread (typically the system workqueue handling SNTP timeout), it immediately closes and detaches the UDP socket descriptor and returns the net_context to the pool. Because net_context objects are reused from a fixed pool (CONFIG_NET_MAX_CONTEXTS), the freed context may be reallocated before the poll thread wakes and unlinks its poller node, leaving a dangling reference. This creates a use-after-free condition on kernel poll structures. The normal SNTP timeout path—triggered when no response arrives—makes this race easy for a remote attacker to exploit by dropping SNTP packets. The fix moves socket closure to the socket service thread via net_socket_service_close, ensuring the polling and closing operations happen synchronously on the same thread.

Business impact

Devices running affected Zephyr versions with SNTP time synchronization enabled face vulnerability to remote denial of service attacks. An attacker with network visibility (on-path or positioned to intercept SNTP traffic) can repeatedly crash the networking subsystem by blocking or dropping time-sync responses. For IoT and embedded systems relying on Zephyr, this impacts availability and may require manual intervention to restore service. Memory corruption remains a secondary risk if the freed context slot is reallocated during the vulnerable window, potentially enabling further exploitation—though the primary manifestation is denial of service.

Affected systems

Zephyr versions 4.2.0 through 4.4.0 are affected. Systems must be using the asynchronous SNTP client with network socket services enabled and relying on SNTP for time initialization or periodic resynchronization (NET_CONFIG_SNTP_INIT_RESYNC). Embedded and IoT deployments using these Zephyr versions for networked time-keeping are at risk. Verify your Zephyr version and SNTP configuration in prj.conf or your build configuration.

Exploitability

Exploitability requires network access to the target device (remote attackers can do this on shared networks or from the internet if SNTP is exposed) and the ability to drop or delay SNTP responses. This can be achieved via passive packet dropping, active man-in-the-middle positioning, or by hosting a malicious or unresponsive SNTP server if the device connects to attacker-controlled infrastructure. No user interaction or special privileges are required. The normal timeout behavior makes the race window repeatable and relatively easy to hit, though precise timing and threading behavior may vary by deployment. The CVSS score of 6.5 reflects the remote, network-accessible attack vector and high availability impact, tempered by the luck-based (AC:H) nature of hitting the race condition.

Remediation

Upgrade to Zephyr version 4.5.0 or later, where the fix has been integrated. The patch changes sntp_close_async to defer socket closure to the socket service thread via net_socket_service_close, eliminating the cross-thread race. If immediate upgrade is not feasible, disable SNTP auto-initialization or periodic resynchronization in your build (unset NET_CONFIG_SNTP_INIT_RESYNC and related SNTP flags), or run SNTP operations on the same thread as the socket service to avoid the trigger condition—though these are workarounds rather than proper fixes.

Patch guidance

Zephyr users should update to version 4.5.0 or later. The fix is backported to the stable branches for v4.2.x, v4.3.x, and v4.4.x as security patches. Check the Zephyr release notes and security advisories at zephyrproject.org for the specific patch version corresponding to your branch. Apply the patch using your standard dependency management (west update or direct source rebuild). Test SNTP functionality in your application after patching to ensure time synchronization operates normally.

Detection guidance

Monitor for repeated networking thread crashes or restarts correlated with SNTP timeout messages in system logs. Kernel oops or panic logs mentioning poll structures, net_context, or use-after-free patterns are indicators. If possible, capture network traffic to identify if SNTP responses are being dropped or delayed to the device. Enable kernel debug logging for net_socket_service and SNTP subsystems (CONFIG_LOG_* for these modules) to observe socket lifecycle events and detect anomalous close/reallocation patterns. In production, watchdog resets or unexpected network subsystem restarts during time-sync initialization may signal active exploitation.

Why prioritize this

While the CVSS score is 6.5 (medium), this vulnerability warrants prompt attention because (1) it targets availability of networked devices in a fundamental way—the networking stack itself—(2) the attack surface is broad (any on-path or network-visible attacker can drop SNTP packets), (3) the normal failure mode (timeout) makes the race condition repeatable without exotic conditions, and (4) Zephyr's use in IoT and embedded systems means affected deployments often lack rapid patching cycles. Organizations running Zephyr 4.2–4.4 with SNTP enabled should treat this as a near-term upgrade priority.

Risk score, explained

CVSS 6.5 reflects a remote, unauthenticated network attack (AV:N, PR:N, UI:N) with no integrity risk (C:N, I:L) but high availability impact (A:H). The AC:H rating acknowledges that the race condition, while repeatable via SNTP timeout, depends on thread scheduling and timing specifics. The impact is scoped to the device itself (S:U). The score balances the real but somewhat ephemeral nature of the race condition against the high-impact consequence (DoS of networking). An attacker must sustain packet dropping to repeatedly trigger the condition, adding friction compared to simple remote code execution.

Frequently asked questions