Description

The PSA Protected Storage credential backend (subsys/net/lib/tls_credentials/tls_credentials_trusted.c) declared its credential-store mutex as a plain zero-filled static struct k_mutex credential_lock; and never called k_mutex_init() on it. A statically zero-filled k_mutex has an uninitialized wait queue (its dlist head/tail are NULL instead of the self-referential sentinels that k_mutex_init/K_MUTEX_DEFINE install). The uncontended lock path does not touch the wait queue, so the defect is latent and serialized use behaves correctly. When two execution contexts contend on the lock, k_mutex_lock() pends the blocking thread on the wait queue via z_pend_curr(), which calls sys_dlist_append() on the zeroed list and dereferences a NULL tail pointer (tail->next = node), faulting the kernel. The lock is held during TLS handshake credential loading and by all credential add/get/delete operations, so a deployment performing concurrent TLS handshakes (for example a server handling multiple simultaneous connections from a remote peer) or a credential-management operation concurrent with a handshake can trigger the dereference. The impact is a denial of service: a deterministic kernel panic / device reset on the first contention. There is no memory corruption beyond the NULL dereference and no confidentiality or integrity impact; mutual exclusion on the fast path remains correct. Exposure is limited to builds with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled (PSA Protected Storage / TF-M platforms); the default volatile RAM backend initializes its lock correctly and is unaffected. The fix initializes the mutex statically with K_MUTEX_DEFINE(credential_lock), providing a valid wait queue so the contended path no longer touches a NULL list.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-12T05:17:42.010Z",
  "pubdate": "2026-08-12T05:17:42.010Z",
  "executiveSummary": "A null pointer dereference vulnerability exists in the PSA Protected Storage credential backend within the subsys/net/lib/tls_credentials/tls_credentials_trusted.c file. The vulnerability stems from an uninitialized kernel mutex that lacks a proper initialization call, resulting in zero-filled internal list pointers. The impact of this defect is a deterministic denial of service via a kernel panic and device reset upon lock contention. The affected systems are deployments utilizing the PSA Protected Storage or TF-M platforms with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled. The risk implication is operational instability and service disruption for multi-threaded or concurrent environments. Attacker capabilities are limited to triggering a denial of service; there is no memory corruption, confidentiality breach, or integrity violation associated with this flaw. Exploitation requirements include concurrent execution contexts attempting to access the credential store simultaneously, such as a server handling multiple parallel TLS handshakes or concurrent credential management operations.",
  "technicalDetails": "The vulnerability resides in the credential-store locking mechanism implemented within subsys/net/lib/tls_credentials/tls_credentials_trusted.c. The root cause is the declaration of the credential-store mutex as a plain zero-filled static struct k_mutex credential_lock without ever invoking the k_mutex_init() function. In the underlying operating system kernel architecture, a statically zero-filled k_mutex contains an uninitialized wait queue where its double-linked list head and tail pointers are NULL, rather than being correctly initialized as self-referential sentinels by initialization routines like k_mutex_init() or K_MUTEX_DEFINE.\nUnder normal execution where the lock is uncontended, the execution path does not touch the wait queue. Consequently, the defect remains latent, and serialized operations function correctly. However, when two or more execution contexts contend on the lock, k_mutex_lock() attempts to pend the blocking thread on the wait queue by calling z_pend_curr(). This internal function subsequently invokes sys_dlist_append() on the zeroed list, which directly dereferences the NULL tail pointer via the tail->next = node assignment. This dereference operation immediately faults the kernel.\nThe attack flow requires concurrent access to paths protected by credential_lock. This lock is actively held during TLS handshake credential loading as well as during all credential add, get, and delete operations. Therefore, a remote peer or local subsystem can trigger the vulnerability by initiating concurrent TLS handshakes, such as a server processing multiple simultaneous connection requests, or by executing a credential-management operation concurrently with an active TLS handshake. Upon race condition manifestation and subsequent contention, the kernel executes the null pointer dereference, resulting in a deterministic kernel panic and immediate device reset.\nExposure is strictly restricted to builds compiled with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled, targeting PSA Protected Storage and Trusted Firmware-M (TF-M) platforms. The default volatile RAM backend correctly initializes its respective synchronization primitives and remains unaffected. No authentication, privileges, or network exposure beyond the ability to initiate concurrent TLS handshakes or credential operations are required to trigger the failure."
}