CVE-2026-82390 in Zephyr
Summary
by MITRE • 10/26/2026
The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (default 4) independent sessions, each carrying its own key and direction. The AES peripheral, however, has a single chip-global set of key and mode registers, and aes_begin_session() programmed them exactly once, at session start, outside the aes_lock mutex that serialises the transforms. The per-operation handlers aes_ecb_op(), aes_cbc_op() and aes_ctr_op() then ran aes_hal_transform_block() against whatever key and direction the registers happened to hold.
As a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session's key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of "each thread does begin, then op, then free on its own session" also races: a second thread's cipher_begin_session() landing between the first thread's begin and its operation makes that operation run under the second thread's key. An attacker who can induce session creation on the device — for example a protocol peer whose connection causes a session key to be installed — can influence which key is resident when a victim operation runs.
The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted under another. Where the resident key is one the attacker knows or supplied, the affected plaintext becomes recoverable by that attacker, and the operation's direction (encrypt versus decrypt) can likewise be inverted. Exposure requires an application that holds two or more concurrent sessions with different keys against this driver; no in-tree Zephyr subsystem does so today (the 802.15.4 security layer, which does open two sessions, uses CCM mode, which this driver rejects), so the risk falls on application code that uses the documented multi-session API.
The fix removes all hardware access from aes_begin_session() and reprograms the key and direction at the top of every operation, inside aes_lock, so the chip-global registers can no longer be observed stale by another session.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability in the Espressif AES driver for Zephyr represents a critical cryptographic failure stemming from improper synchronization of hardware register access during multi-session operations. The driver advertises an API capable of managing up to four independent cipher sessions, each theoretically maintaining its own encryption key and operational direction such as encrypt or decrypt. However, the underlying ESP32 AES peripheral utilizes chip-global registers for storing keys and mode settings rather than session-specific storage. This architectural constraint requires careful software-level serialization to ensure that operations on one session do not inadvertently overwrite the configuration intended for another. The core flaw lies in the implementation of aes_begin_session(), which programs these global key and direction registers outside the scope of the aes_lock mutex. This mutex is designed to serialize concurrent access to shared resources, but by bypassing it during initialization, the driver creates a race condition where the state of the hardware registers becomes inconsistent with the logical session context.
When an application opens multiple sessions with different keys, the first thread to call begin_session programs its key into the global register. Subsequent threads calling begin_session overwrite this value with their own distinct keys without holding the lock that protects subsequent operations. Consequently, any operation performed on a previously established session may execute using the most recently programmed key rather than the one associated with that specific session. This results in silent data corruption where plaintext intended to be protected under one cryptographic key is instead encrypted or decrypted under another. The lack of error reporting exacerbates the issue as applications remain unaware that their security guarantees have been compromised, leading to a complete breakdown of confidentiality and integrity for affected communications.
The operational impact extends beyond simple data exposure due to the potential inversion of operation direction. Since the directional setting such as encrypt versus decrypt is also stored in these global registers, an attacker who can induce session creation on the device may influence which key and mode are active when a victim operation executes. If an attacker supplies or knows the key used by a second session that races with a first session's operation, they gain the ability to recover plaintext data that was believed to be secure under a different key. Furthermore, if the direction is inverted, encrypted traffic might be decrypted using the wrong key or vice versa, leading to further cryptographic failures and potential protocol breakdowns. This scenario assumes an attacker can trigger session creation through network interactions or other means of inducing concurrent cipher operations on the device.
Mitigation strategies must address both immediate code fixes and broader architectural considerations. The primary remediation involves refactoring aes_begin_session() to remove all hardware access from that function entirely. Instead, key programming and direction setting should occur at the beginning of every individual operation handler such as aes_ecb_op or aes_cbc_op while holding the aes_lock mutex. This ensures that each cryptographic transformation uses the correct context-specific parameters regardless of concurrent session activity. Additionally, developers utilizing this driver must audit their application logic to ensure they do not rely on persistent multi-session states with different keys unless these mitigations are applied. While no in-tree Zephyr subsystem currently exploits this vulnerability due to specific mode restrictions like CCM rejection by the AES ECB CBC and CTR implementations, external applications using the documented API remain at risk until patched.
From a classification perspective, this vulnerability aligns with CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization which describes race conditions arising from inadequate locking mechanisms. It also relates to CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes as the application's control over cryptographic parameters is subverted by concurrent access patterns. In terms of attack vectors, this falls under ATT&CK T1498 Network Denial of Service if considered via resource exhaustion or more accurately T1076 Remote Data Encrypted for Impact when considering the potential for data manipulation and exfiltration through key substitution. The severity is heightened by the fact that it affects fundamental cryptographic primitives used in secure communications, making timely patching essential for any deployment relying on concurrent AES operations with distinct keys.