CVE-2026-87044 in Zephyr
Summary
by MITRE • 11/04/2026
The Mbed TLS crypto shim driver in drivers/crypto/crypto_mbedtls_shim.c drives PSA multipart cipher and AEAD operations. In mbedtls_cbc() and mbedtls_aead(), every error path after a successful psa_cipher_encrypt_setup() / psa_aead_decrypt_setup() returned directly without calling psa_cipher_abort() / psa_aead_abort(). Because the abort is the only thing that reaches mbedtls_cipher_free(), each failed operation permanently leaked the heap-allocated mbedtls_aes_context (roughly 288 bytes) that setup had allocated from Mbed TLS's fixed static heap (_mbedtls_heap[CONFIG_MBEDTLS_HEAP_SIZE], default 512 bytes). With CONFIG_PSA_CRYPTO_PROVIDER_TFM the leaked object is instead a finite secure-partition multipart-operation slot.
The failure is chosen by an unauthenticated attacker. With CONFIG_NET_L2_IEEE802154_SECURITY backed by this driver, ieee802154_decrypt_auth() in subsys/net/l2/ieee802154/ieee802154_security.c invokes cipher_ccm_op() on every received secured frame, with no authentication ahead of the MIC check. A device in radio range can transmit a stream of syntactically valid 802.15.4 frames carrying a bogus MIC; each one makes psa_aead_verify() fail and leaks a block. The CBC path is reachable the same way through the OSDP secure channel, where CONFIG_OSDP_SC_ENABLED selects this shim and osdp_encrypt() / osdp_decrypt() leave out_buf_max unset, so every operation fails inside psa_cipher_update().
Exhausting the Mbed TLS heap — which the default configuration reaches after a couple of failed operations, and any realistic configuration reaches in well under a second of frames — makes all subsequent mbedtls_calloc() calls fail. Every later cryptographic operation in the image then fails permanently, including link-layer security and any TLS/DTLS sharing the same heap, until the device is rebooted. There is no memory corruption or information disclosure: frames with an invalid MIC are still rejected, so the impact is limited to availability.
The fix routes all post-setup failures in mbedtls_cbc() and mbedtls_aead() through a common error: label that calls the matching PSA abort before returning. Setup failures need no change, since the PSA core aborts the operation itself when setup fails.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
This vulnerability represents a critical resource exhaustion flaw within the Mbed TLS crypto shim driver used in embedded systems running Zephyr RTOS. The issue stems from improper cleanup procedures during multipart cryptographic operations, specifically affecting CBC and AEAD modes. When functions such as mbedtls_cbc() or mbedtls_aead() are invoked to handle encryption or decryption tasks, they rely on PSA (Platform Security Architecture) APIs for setup. If the initial setup phase succeeds but a subsequent update or finalization step fails due to invalid input data, the code path returns immediately without invoking the corresponding abort function. In standard Mbed TLS workflows, calling psa_cipher_abort() or psa_aead_abort() is mandatory to release resources allocated during the setup phase. The absence of this call means that every failed operation leaves behind a permanently leaked memory block. For configurations using the default static heap size of 512 bytes, each leak consumes approximately 288 bytes for an AES context object. In secure partition environments utilizing CONFIG_PSA_CRYPTO_PROVIDER_TFM, the consequence is equally severe as it depletes finite multipart-operation slots reserved for trusted execution environment tasks.
The operational impact of this flaw is primarily a denial-of-service condition that can be triggered remotely by an unauthenticated attacker within radio range. The vulnerability is particularly acute in devices utilizing IEEE 802.15.4 security, where the subsystem invokes cipher_ccm_op() on every received frame to verify integrity and decrypt data. Because authentication checks are performed after decryption attempts using PSA AEAD verification functions, an adversary can flood the device with syntactically valid frames containing maliciously crafted Message Integrity Codes (MICs). Each such frame causes psa_aead_verify() to fail, triggering the buggy error path that leaks memory without aborting the operation. Similarly, devices employing Open Supervised Device Protocol secure channels are susceptible because configuration settings leave output buffer maximum sizes unset, causing operations to fail inside psa_cipher_update(). This allows an attacker to systematically exhaust the cryptographic heap by sending a continuous stream of invalid frames.
The consequences of exhausting the Mbed TLS static heap extend beyond the immediate failure of individual cryptographic calls. Once the fixed-size heap is depleted, all subsequent attempts to allocate memory for any cryptographic operation within the image will fail permanently via mbedtls_calloc(). This effectively disables link-layer security mechanisms and breaks higher-level protocols like TLS or DTLS that share the same underlying crypto infrastructure. The device becomes unable to perform secure communications until a reboot resets the static allocation pool. It is important to note that this vulnerability does not lead to memory corruption, arbitrary code execution, or information disclosure. Frames with invalid MICs are correctly rejected by the verification logic, ensuring confidentiality and integrity remain intact despite the availability impact.
From a classification perspective, this flaw aligns with CWE-401, which describes missing release of memory after successful allocation, leading to resource exhaustion. In terms of attack vectors, it corresponds to ATT&CK technique T1499, specifically endpoint denial of service via resource flooding or loop injection. The remediation strategy involves refactoring the error handling paths in mbedtls_cbc() and mbedtls_aead() to route all post-setup failures through a common label that explicitly calls the matching PSA abort function before returning an error code. This ensures that resources allocated during setup are properly released regardless of where the operation fails downstream. Setup failures themselves do not require modification as the PSA core handles cleanup when initialization does not complete successfully, but the critical gap lies in handling errors after successful allocation and partial execution.