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.