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.

Affected components

• subsys/net/lib/sntp
• subsys/net/lib/config
• subsys/net/lib/sockets

Affected versions

v4.2.0, v4.2.1, v4.2.2, v4.3.0, v4.4.0 (async SNTP API present since v4.2.0)

Fix

Fixed (merged) in ef47bdf

Projected fixed version: 4.5.0 (the fix is merged on main but not yet released; this forecast should be confirmed against the actual release).

Introduced by: 7ab8e27 (net: lib: sntp: async query API, 2025-03-07)

Evidence

• subsys/net/lib/sntp/sntp.c:344-348 — post-fix sntp_close_async defers close via net_socket_service_close; git show v4.4.0:... shows pre-fix caller-thread zsock_close(ctx->sock.fd)
• subsys/net/lib/sockets/sockets_service.c:241-259 — poll thread snapshots fds under lock then zsock_poll()s without the lock; close now happens in-thread at restart: (lines 245-251)
• lib/os/zvfs/zvfs_poll.c:48-109 — POLL_PREPARE then k_poll() blocks referencing per-fd objects without holding a refcount during the wait
• subsys/net/lib/sockets/sockets_inet.c:1660-1674 — zsock_poll_prepare_ctx sets (*pev)->obj = &ctx->recv_q, a pointer into the net_context that a concurrent close frees
• subsys/net/ip/net_context.c:80 — net_context objects live in a fixed reusable array contexts[NET_MAX_CONTEXT], so a freed context can be reallocated under the dangling poll registration
• subsys/net/lib/config/init_clock_sntp.c:139-166 — sntp_async_timeout runs on the system workqueue and calls sntp_close_async, racing the socket service thread's poll; timeout is the normal no-response path an attacker can force
• include/zephyr/net/socket_service.h:179-196 — net_socket_service_unregister (old) vs net_socket_service_close (new) showing the deferred-close mechanism
• git tag --contains 7ab8e27 — vulnerable code present in v4.2.0/v4.3.0/v4.4.0; fix dated 2026-05-01 after v4.4.0

Patches

For more information

If you have any questions or comments about this advisory:

• Open an issue in zephyr
• Email us at Zephyr-vulnerabilities

embargo: 2026-06-30