zephyrproject zephyr up to 4.4.x Network Socket Service sntp.c recv_q use after free

Summaryinfo

A vulnerability marked as critical has been reported in zephyrproject zephyr up to 4.4.x. This impacts an unknown function in the library subsys/net/lib/config/init_clock_sntp.c of the file subsys/net/lib/sntp/sntp.c of the component Network Socket Service. Performing a manipulation of the argument recv_q results in use after free. This vulnerability is cataloged as CVE-2026-10655. It is possible to initiate the attack remotely. There is no exploit available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in zephyrproject zephyr up to 4.4.x. This affects an unknown code in the library subsys/net/lib/config/init_clock_sntp.c of the file subsys/net/lib/sntp/sntp.c of the component Network Socket Service. The manipulation of the argument recv_q with an unknown input leads to a use after free vulnerability. CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-10655 since 06/02/2026. The exploitability is told to be difficult. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available.

Upgrading to version 4.5.0 eliminates this vulnerability. Applying the patch ef47bdf328b4206ac3b3922ec09184f7a6f7412a is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• zephyrproject

Name

• zephyr

Version

• 4.0
• 4.1
• 4.2
• 4.3
• 4.4

License

• open-source

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion