Answer in brief
CVE-2026-15924 records a Unknown severity vulnerability in Use-after-free / double-free from unsynchronized concurrent access to the TLS client session cache in Zephyr sockets. The current sources do not mark it as known exploited. The current feed maps zephyrproject/zephyr (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps zephyrproject/zephyr (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| zephyrproject/zephyrgeneric | >=3.1.0 <4.4.2 | 4.4.2 |
Published upstream
Sep 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 14, 2026
Zephyr's TLS socket layer in subsys/net/lib/sockets/sockets_tls.c keeps a single process-global array, client_cache, of cached client sessions that is shared by every TLS socket context. The functions that mutate and read it — tls_session_save(), tls_session_get(), tls_session_cache_reset(), and the settings restore handler — allocate, free, and dereference each entry's heap buffer (entry->session). Before the fix these accesses were serialized only by the per-socket context mutex ctx->lock (assigned per socket in ctx_set_lock()), which provides no mutual exclusion between different sockets touching the shared cache. Because CONFIG_NET_SOCKETS_TLS_MAX_CLIENT_SESSION_COUNT defaults to 1, any two concurrent client sockets contend for the same slot. A thread in tls_session_get() reading entry->session inside mbedtls_ssl_session_load() can run concurrently with another thread in tls_session_save() that selects the same entry for reuse and executes mbedtls_free(entry->session) before reallocating — a use-after-free read, and a double-free when two saves evict the same entry. Both corrupt the mbedTLS heap. The cache is reached on ordinary client paths: at connect time via tls_session_store()/tls_session_restore(), and (on main) whenever a TLS 1.3 session ticket arrives during recv()/poll() via tls_session_store_current(). Exploitation requires an application that opts into per-socket client session caching (the TLS_SESSION_CACHE socket option, off by default) and runs concurrent TLS client connections on multiple threads; the timing that opens the window is influenced by the remote peer(s), so a malicious or compromised server can raise session-ticket frequency to widen it. The reliably-demonstrable impact is memory corruption leading to a crash or heap corruption (denial of service). The fix adds a dedicated session_cache_lock mutex taken across every accessor of client_cache, serializing all reads and frees and closing the race.
Quoted source text, attributed separately from HOL analysis.