Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-14T20:16:38.907Z",
  "pubdate": "2026-09-14T20:16:38.907Z",
  "executiveSummary": "The Zephyr Project's TLS socket layer suffers from a concurrency-based memory corruption vulnerability located in the global client session cache.\nThe vulnerability stems from inadequate locking mechanisms during TLS session management, specifically in files associated with TLS socket handling.\nWhen multiple concurrent TLS client sockets are active, the lack of thread safety leads to race conditions, causing use-after-free reads and double-free events within the mbedTLS heap.\nThis flaw can be triggered by an attacker controlling a malicious or compromised server, which can manipulate TLS session ticket frequency to widen the race condition window.\nSuccessful exploitation results in heap memory corruption, leading to system instability, potential arbitrary code execution paths, or a reliable Denial of Service (DoS) via crash.\nThe vulnerability is limited to applications that explicitly enable the TLS_SESSION_CACHE socket option. Mitigation requires implementing centralized serialization for cache access.",
  "technicalDetails": "The root cause of this vulnerability is improper synchronization in subsys/net/lib/sockets/sockets_tls.c, where the 'client_cache' global array is accessed by multiple threads without sufficient mutual exclusion.\nWhile each individual socket utilizes 'ctx->lock', this per-socket lock is insufficient to protect the global shared cache. Because 'CONFIG_NET_SOCKETS_TLS_MAX_CLIENT_SESSION_COUNT' defaults to 1, any contention between concurrent client sockets forces them to operate on the same shared memory slot.\nThe vulnerability manifests during two primary operations: 'tls_session_get()' and 'tls_session_save()'. An attacker-controlled server can induce a race condition by forcing frequent TLS 1.3 session ticket updates. In this scenario, one thread executing 'tls_session_get()' may be reading 'entry->session' via 'mbedtls_ssl_session_load()' while another thread executing 'tls_session_save()' concurrently determines that the cache entry is stale or requires replacement.\nThe 'tls_session_save()' function triggers 'mbedtls_free(entry->session)' to clear existing data before reallocating. If the timing aligns, the reader thread accesses the freed memory, resulting in a use-after-free. If two threads attempt to evict the same entry simultaneously, a double-free occurs. Both scenarios directly corrupt the mbedTLS heap structure, as the allocator is forced into an inconsistent state by the concurrent modifications.\nThe attack flow requires the target application to have opted into 'TLS_SESSION_CACHE'. The attacker, acting as a remote TLS server, initiates multiple concurrent connections or intentionally floods session tickets to increase the probability of overlapping critical sections. Once the heap is corrupted, the attacker can influence subsequent memory allocations, potentially bypassing security boundaries or triggering a kernel-level panic.\nThis race condition is essentially a synchronization failure where the granularity of the locking mechanism does not match the scope of the shared resource (the global session cache). The absence of a global 'session_cache_lock' allows the race window to remain open indefinitely, exposing the mbedTLS heap management to unpredictable manipulation."
}