https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 28 Oct 2026 21:34:14 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-82390 <p>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.</p> <p>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&#39;s key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of &#34;each thread does begin, then op, then free on its own session&#34; also races: a second thread&#39;s cipher_begin_session() landing between the first thread&#39;s begin and its operation makes that operation run under the second thread&#39;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.</p> <p>The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted…</p> <p>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.</p> <p>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&#39;s key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of &#34;each thread does begin, then op, then free on its own session&#34; also races: a second thread&#39;s cipher_begin_session() landing between the first thread&#39;s begin and its operation makes that operation run under the second thread&#39;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.</p> <p>The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted…</p> https://db.gcve.eu/vuln/fkie_cve-2026-82390 https://db.gcve.eu/vuln/ubuntu-cve-2026-82390 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: zephyr, Ubuntu:18.04:LTS: zephyr, Ubuntu:20.04:LTS: zephyr, Ubuntu:22.04:LTS: zephyr, Ubuntu:24.04:LTS: zephyr, Ubuntu:26.10: zephyr, Ubuntu:26.04:LTS: zephyr</p> <p>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&#39;s key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of &#34;each thread does begin, then op, then free on its own session&#34; also races: a second thread&#39;s cipher_begin_session() landing between the first thread&#39;s begin and its operation makes that operation run under the second thread&#39;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 un…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: zephyr, Ubuntu:18.04:LTS: zephyr, Ubuntu:20.04:LTS: zephyr, Ubuntu:22.04:LTS: zephyr, Ubuntu:24.04:LTS: zephyr, Ubuntu:26.10: zephyr, Ubuntu:26.04:LTS: zephyr</p> <p>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&#39;s key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of &#34;each thread does begin, then op, then free on its own session&#34; also races: a second thread&#39;s cipher_begin_session() landing between the first thread&#39;s begin and its operation makes that operation run under the second thread&#39;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 un…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-82390