CVE-2026-10655: use-after-free in zephyrproject zephyr
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.
AI Analysis
Technical Summary
The vulnerability in Zephyr's asynchronous SNTP client arises from closing the UDP socket file descriptor immediately after detaching it from the network socket service without synchronization with the socket-service poll thread. The poll thread registers poll events pointing into net_context objects, which are freed and potentially reused by the close operation running on a different thread. This race condition leads to use-after-free and object confusion in kernel poll structures. The typical trigger is the SNTP timeout path, where delayed or dropped SNTP/NTP responses cause repeated racing closes. The fix defers socket closure to the socket service thread itself, ensuring the same thread that polls also performs the close, thus preventing the race. Affected versions are Zephyr v4.2.0 through v4.4.0.
Potential Impact
The vulnerability can cause a denial of service by crashing the networking thread due to use-after-free of kernel poll structures. There is also potential for memory corruption when the freed net_context slot is reallocated. No direct confidentiality or integrity impact is described. The attack vector is network-based, requiring an attacker to drop or delay SNTP/NTP responses to trigger the race condition.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix defers socket closure to the socket service thread to eliminate the race condition. Until an official fix is available, avoid network conditions that cause SNTP timeouts or consider disabling the asynchronous SNTP client if feasible.
CVE-2026-10655: use-after-free in zephyrproject zephyr
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 v3.1
Score 6.5medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in Zephyr's asynchronous SNTP client arises from closing the UDP socket file descriptor immediately after detaching it from the network socket service without synchronization with the socket-service poll thread. The poll thread registers poll events pointing into net_context objects, which are freed and potentially reused by the close operation running on a different thread. This race condition leads to use-after-free and object confusion in kernel poll structures. The typical trigger is the SNTP timeout path, where delayed or dropped SNTP/NTP responses cause repeated racing closes. The fix defers socket closure to the socket service thread itself, ensuring the same thread that polls also performs the close, thus preventing the race. Affected versions are Zephyr v4.2.0 through v4.4.0.
Potential Impact
The vulnerability can cause a denial of service by crashing the networking thread due to use-after-free of kernel poll structures. There is also potential for memory corruption when the freed net_context slot is reallocated. No direct confidentiality or integrity impact is described. The attack vector is network-based, requiring an attacker to drop or delay SNTP/NTP responses to trigger the race condition.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix defers socket closure to the socket service thread to eliminate the race condition. Until an official fix is available, avoid network conditions that cause SNTP timeouts or consider disabling the asynchronous SNTP client if feasible.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-06-02T15:24:29.575Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a43f42f27e9c79719185ecb
Added to database: 06/30/2026, 16:51:59 UTC
Last enriched: 07/15/2026, 10:47:45 UTC
Last updated: 08/14/2026, 00:45:19 UTC
Views: 71
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.