CVE-2026-12233 in Zephyr
Summary
by MITRE • 08/12/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability exists within the PSA Protected Storage credential backend implementation in Zephyr OS, specifically in the file subsys/net/lib/tls_credentials/tls_credentials_trusted.c. This flaw stems from improper initialization of a static mutex variable that serves as the credential store lock. The declaration static struct k_mutex credential_lock; creates a zero-filled structure without invoking k_mutex_init() to properly initialize its internal data structures. According to CWE-665, this represents an improper initialization of a resource where the mutex's wait queue remains uninitialized with NULL pointers instead of the required self-referential sentinels that would normally be established by proper initialization functions.
The technical execution path of this vulnerability becomes apparent when multiple execution contexts attempt to acquire the same mutex simultaneously. While the uncontended lock path operates correctly since it doesn't interact with the wait queue, the contended scenario triggers a kernel panic through a NULL pointer dereference. When k_mutex_lock() attempts to pend a blocking thread via z_pend_curr(), this function calls sys_dlist_append() on the zero-initialized list structure. The failure occurs because the tail pointer remains NULL, causing tail->next = node to dereference a null pointer and result in immediate kernel faulting.
This vulnerability manifests during concurrent TLS operations where credential loading occurs during TLS handshakes or when credential management operations happen simultaneously with active connections. The impact is a deterministic denial of service condition that results in kernel panic and device reset upon the first instance of lock contention. The ATT&CK technique T1499.004 covers this as a denial of service attack vector through system resource manipulation. As specified in the security advisory, the vulnerability affects only builds with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled, which corresponds to PSA Protected Storage implementations integrated with TrustZone for All platforms. The default volatile RAM backend remains unaffected since it properly initializes its lock mechanism.
The mitigation strategy involves replacing the static mutex declaration with K_MUTEX_DEFINE(credential_lock) macro, which ensures proper initialization of all internal data structures including the wait queue with valid sentinel values. This fix aligns with best practices for kernel-level resource management and prevents the NULL pointer dereference by establishing a proper doubly-linked list structure that can handle thread queuing operations correctly. The solution maintains the existing mutual exclusion semantics on the fast path while resolving the latent race condition in the contended code path, ensuring that concurrent TLS operations and credential management activities can proceed without triggering kernel panics.