CVE-2026-10655
Received Received - Intake

Use-After-Free in Zephyr SNTP Client

Publication date: 2026-06-30

Last updated on: 2026-06-30

Assigner: Zephyr Project

Description
The asynchronous SNTP client in Zephyr (subsys/net/lib/sntp/sntp.c, sntp_close_async) closed the UDP socket file descriptor directly from the calling thread immediately after detaching it from the network socket service, without synchronizing with the socket-service poll thread. The socket service thread polls each socket via zvfs_poll, which (in zsock_poll_prepare_ctx) registers a k_poll_event pointing into the socket's net_context (&ctx->recv_q) and then blocks in k_poll without holding a reference or lock. net_context objects are allocated from a fixed pool (contexts[CONFIG_NET_MAX_CONTEXTS]) and reused after close. When sntp_close_async is invoked from a different thread than the poll thread (in the in-tree consumer subsys/net/lib/config/init_clock_sntp.c, the SNTP timeout handler runs on the system workqueue while the socket service thread is blocked in poll on the same fd), the close frees and may reuse the net_context while the poll thread still has a poller node linked into the freed object, resulting in a use-after-free / object confusion of kernel poll structures. The SNTP timeout path is the normal no-response failure mode, so a network peer or off-path attacker who drops or delays the SNTP/NTP response can drive the racing close repeatedly (and periodically with NET_CONFIG_SNTP_INIT_RESYNC). The most likely consequence is a crash of the networking thread (denial of service), with potential memory corruption when the freed context slot is reallocated. The fix defers the close to the socket service thread itself via net_socket_service_close (NET_SOCKET_SERVICE_CLOSE_SOCKETS), so the same thread that polls performs the close, eliminating the race. Affected releases: v4.2.0 through v4.4.0.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-06-30
Last Modified
2026-06-30
Generated
2026-06-30
AI Q&A
2026-06-30
EPSS Evaluated
N/A
NVD
CVE-2026-10655
EUVD
EUVD-2026-40370

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
zephyrproject zephyr From 4.2.0 (inc) to 4.4.0 (inc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

The CVE-2026-10655 vulnerability in the Zephyr RTOS involves a use-after-free race condition in the asynchronous SNTP (Simple Network Time Protocol) client.

The issue occurs because the SNTP client's sntp_close_async function closes the UDP socket file descriptor directly from the calling thread without synchronizing with the socket-service poll thread, which may still be referencing the socket's memory.

This can lead to a use-after-free scenario where the freed net_context object is reused while the poll thread still holds a reference to it, causing memory corruption or a crash.

The vulnerability is triggered when an attacker delays or drops SNTP/NTP responses, forcing repeated timeouts and closures.

The fix defers the socket close operation to the socket service thread itself, eliminating the race condition.

Impact Analysis

This vulnerability can cause a crash of the networking thread, resulting in a denial of service.

There is also potential for memory corruption when the freed net_context slot is reallocated while still referenced by the poll thread.

An attacker who drops or delays SNTP/NTP responses can repeatedly trigger this race condition, causing periodic disruptions.

Detection Guidance

This vulnerability involves a race condition in the asynchronous SNTP client of Zephyr RTOS, specifically when the socket is closed from a different thread while the socket service thread is still polling it. Detection would involve monitoring for crashes or instability in the networking thread related to SNTP socket handling.

Since the issue is triggered by delayed or dropped SNTP/NTP responses causing repeated socket closures, monitoring SNTP traffic for unusual delays or dropped packets could help identify potential exploitation attempts.

There are no specific commands provided in the resources to detect this vulnerability directly. However, general approaches could include:

  • Monitoring system logs for networking thread crashes or kernel errors related to socket polling or SNTP.
  • Using network packet capture tools (e.g., tcpdump or Wireshark) to observe SNTP/NTP traffic delays or dropped responses.
  • Checking the Zephyr RTOS version to see if it falls within the affected range (v4.2.0 through v4.4.0).
Mitigation Strategies

The primary mitigation is to update the Zephyr RTOS to version 4.5.0 or later, where the fix for this vulnerability has been applied.

The fix defers the socket close operation to the socket service thread itself, ensuring proper synchronization and eliminating the race condition.

If immediate upgrading is not possible, consider minimizing exposure by limiting SNTP traffic from untrusted sources or implementing network-level controls to prevent attackers from dropping or delaying SNTP/NTP responses.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-10655. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart