CVE-2026-12233

{"id": "CVE-2026-12233", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-12233", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "version": "2.0.3", "timestamp": "2026-08-13T15:09:49.771424Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "vulnerabilities@zephyrproject.org", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.9, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 2.2}]}, "affected": [{"source": "vulnerabilities@zephyrproject.org", "affectedData": [{"vendor": "zephyrproject", "product": "zephyr", "versions": [{"status": "affected", "version": "3.2.0", "lessThan": "4.4.2", "versionType": "semver"}], "packageName": "zephyr", "programFiles": ["subsys/net/lib/tls_credentials/tls_credentials_trusted.c"], "collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "defaultStatus": "unaffected"}]}], "published": "2026-08-12T05:17:42.010", "references": [{"url": "https://github.com/zephyrproject-rtos/zephyr/commit/29581d586f3d68ec8bb1448b522e5470d4a06aa9", "source": "vulnerabilities@zephyrproject.org"}, {"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-57c4-xcq2-fqj7", "source": "vulnerabilities@zephyrproject.org"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "vulnerabilities@zephyrproject.org", "description": [{"lang": "en", "value": "CWE-665"}]}], "descriptions": [{"lang": "en", "value": "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.\n\nWhen 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.\n\nThe 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.\n\nThe 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."}, {"lang": "es", "value": "El backend de credenciales de PSA Protected Storage (subsys/net/lib/tls_credentials/tls_credentials_trusted.c) declar\u00f3 su mutex de almac\u00e9n de credenciales como una struct k_mutex credential_lock est\u00e1tica simple rellenada con ceros; y nunca llam\u00f3 a k_mutex_init() sobre ella. Un k_mutex rellenado con ceros est\u00e1ticamente tiene una cola de espera no inicializada (su cabeza/cola de dlist son NULL en lugar de los centinelas autorreferenciales que instalan k_mutex_init/K_MUTEX_DEFINE). La ruta de bloqueo sin contenci\u00f3n no toca la cola de espera, por lo que el defecto es latente y el uso serializado se comporta correctamente.\n\nCuando dos contextos de ejecuci\u00f3n compiten por el bloqueo, k_mutex_lock() suspende el hilo bloqueante en la cola de espera a trav\u00e9s de z_pend_curr(), que llama a sys_dlist_append() en la lista con ceros y desreferencia un puntero de cola NULL (tail -> next = node), provocando un fallo en el kernel. El bloqueo se mantiene durante la carga de credenciales del handshake TLS y por todas las operaciones de a\u00f1adir/obtener/eliminar credenciales, por lo que un despliegue que realice handshakes TLS concurrentes (por ejemplo, un servidor que maneja m\u00faltiples conexiones simult\u00e1neas de un par remoto) o una operaci\u00f3n de gesti\u00f3n de credenciales concurrente con un handshake puede desencadenar la desreferencia.\n\nEl impacto es una denegaci\u00f3n de servicio: un p\u00e1nico de kernel determinista / reinicio del dispositivo en la primera contenci\u00f3n. No hay corrupci\u00f3n de memoria m\u00e1s all\u00e1 de la desreferencia NULL y ning\u00fan impacto en la confidencialidad o integridad; la exclusi\u00f3n mutua en la ruta r\u00e1pida sigue siendo correcta. La exposici\u00f3n se limita a las compilaciones con CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE habilitado (plataformas PSA Protected Storage / TF-M); el backend de RAM vol\u00e1til predeterminado inicializa su bloqueo correctamente y no se ve afectado.\n\nLa soluci\u00f3n inicializa el mutex est\u00e1ticamente con K_MUTEX_DEFINE(credential_lock), proporcionando una cola de espera v\u00e1lida para que la ruta con contenci\u00f3n ya no toque una lista NULL."}], "lastModified": "2026-10-23T20:10:00.160", "sourceIdentifier": "vulnerabilities@zephyrproject.org"}