CVE-2026-15924: Use-after-free / double-free from unsynchronized concurrent access to the TLS client session cache in Zephyr sockets
Zephyr's TLS socket layer in subsys/net/lib/sockets/socketstls.c keeps a single process-global array, clientcache, of cached client sessions that is shared by every TLS socket context. The functions that mutate and read it — tlssessionsave(), tlssessionget(), tlssessioncachereset(), 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 ctxsetlock()), which provides no mutual exclusion between different sockets touching the shared cache.
Because CONFIGNETSOCKETSTLSMAXCLIENTSESSIONCOUNT defaults to 1, any two concurrent client sockets contend for the same slot. A thread in tlssessionget() reading entry->session inside mbedtlssslsessionload() can run concurrently with another thread in tlssessionsave() that selects the same entry for reuse and executes mbedtlsfree(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 tlssessionstore()/tlssessionrestore(), and (on main) whenever a TLS 1.3 session ticket arrives during recv()/poll() via tlssessionstorecurrent().
Exploitation requires an application that opts into per-socket client session caching (the TLSSESSIONCACHE 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 sessioncachelock mutex taken across every accessor of clientcache, serializing all reads and frees and closing the race.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Reduce or avoid concurrent TLS client session caching by ensuring applications do not enable the per-socket TLS client session caching option (TLS_SESSION_CACHE socket option is off by default). This limits concurrent sockets from contending for the shared client_cache slot (CONFIG_NET_SOCKETS_TLS_MAX_CLIENT_SESSION_COUNT defaults to 1).
- Compensating control
If you cannot upgrade immediately, limit the rate/likelihood of TLS 1.3 session ticket arrivals during recv()/poll() (which triggers tls_session_store_current()) to shrink the timing window that can widen the race when connected to malicious/compromised peers.
Event History
Frequently Asked Questions
Is the default configuration affected?
Yes. CONFIG_NET_SOCKETS_TLS_MAX_CLIENT_SESSION_COUNT defaults to 1, so concurrent TLS client sockets contend for the same shared client-session-cache slot by default.
What conditions are needed to trigger the flaw?
At least two TLS client socket operations must access the shared cache concurrently. A session lookup can dereference a cached session while another socket saves a session and frees that same entry, and concurrent saves can both evict the same entry.
What is the practical impact of a successful trigger?
The race can cause a use-after-free read or double-free in the mbedTLS heap. The stated availability impact is high because these conditions corrupt the mbedTLS heap.