CVE-2026-82390 (GCVE-0-2026-82390)
Vulnerability from cvelistv5
Published
2026-10-26 16:08
Modified
2026-10-26 17:37
Severity ?
3.7 (Low) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
CWE
Summary
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.
References
Impacted products
Vendor Product Version
zephyrproject zephyr Version: 4.3.0   ≤ 4.4.2
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-82390",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T16:49:07.670669Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T17:37:10.530Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
          "defaultStatus": "unaffected",
          "packageName": "zephyr",
          "product": "zephyr",
          "programFiles": [
            "drivers/crypto/crypto_esp32_aes.c"
          ],
          "programRoutines": [
            {
              "name": "aes_begin_session"
            },
            {
              "name": "aes_cbc_op"
            },
            {
              "name": "aes_ctr_op"
            },
            {
              "name": "aes_ecb_op"
            }
          ],
          "vendor": "zephyrproject",
          "versions": [
            {
              "lessThanOrEqual": "4.4.2",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API \u2014 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.\n\nAs a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session\u0027s 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\u0027s cipher_begin_session() landing between the first thread\u0027s begin and its operation makes that operation run under the second thread\u0027s key. An attacker who can induce session creation on the device \u2014 for example a protocol peer whose connection causes a session key to be installed \u2014 can influence which key is resident when a victim operation runs.\n\nThe 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\u0027s 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.\n\nThe 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 3.7,
            "baseSeverity": "LOW",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-362",
              "description": "race",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T16:08:54.724Z",
        "orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
        "shortName": "zephyr"
      },
      "references": [
        {
          "name": "Fix commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/zephyrproject-rtos/zephyr/commit/cb4168ab3f6bd1bfc26060fd33cfcd00e8e641f1"
        },
        {
          "name": "GHSA-rvww-w3mx-r99q",
          "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-rvww-w3mx-r99q"
        }
      ],
      "title": "Cross-session AES key confusion in the Espressif ESP32 hardware crypto driver",
      "x_generator": {
        "engine": "cvelib 1.8.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
    "assignerShortName": "zephyr",
    "cveId": "CVE-2026-82390",
    "datePublished": "2026-10-26T16:08:54.724Z",
    "dateReserved": "2026-08-28T21:11:44.241Z",
    "dateUpdated": "2026-10-26T17:37:10.530Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-82390\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-26T16:49:07.670669Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-26T17:35:17.842Z\"}}], \"cna\": {\"title\": \"Cross-session AES key confusion in the Espressif ESP32 hardware crypto driver\", \"metrics\": [{\"format\": \"CVSS\", \"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 3.7, \"baseSeverity\": \"LOW\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N\"}}], \"affected\": [{\"vendor\": \"zephyrproject\", \"product\": \"zephyr\", \"versions\": [{\"status\": \"affected\", \"version\": \"4.3.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.4.2\"}], \"packageName\": \"zephyr\", \"programFiles\": [\"drivers/crypto/crypto_esp32_aes.c\"], \"collectionURL\": \"https://github.com/zephyrproject-rtos/zephyr\", \"defaultStatus\": \"unaffected\", \"programRoutines\": [{\"name\": \"aes_begin_session\"}, {\"name\": \"aes_cbc_op\"}, {\"name\": \"aes_ctr_op\"}, {\"name\": \"aes_ecb_op\"}]}], \"references\": [{\"url\": \"https://github.com/zephyrproject-rtos/zephyr/commit/cb4168ab3f6bd1bfc26060fd33cfcd00e8e641f1\", \"name\": \"Fix commit\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-rvww-w3mx-r99q\", \"name\": \"GHSA-rvww-w3mx-r99q\"}], \"x_generator\": {\"engine\": \"cvelib 1.8.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API \\u2014 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.\\n\\nAs a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session\u0027s 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\u0027s cipher_begin_session() landing between the first thread\u0027s begin and its operation makes that operation run under the second thread\u0027s key. An attacker who can induce session creation on the device \\u2014 for example a protocol peer whose connection causes a session key to be installed \\u2014 can influence which key is resident when a victim operation runs.\\n\\nThe 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\u0027s 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.\\n\\nThe 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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-362\", \"description\": \"race\"}]}], \"providerMetadata\": {\"orgId\": \"e2e69745-5e70-4e92-8431-deb5529a81ad\", \"shortName\": \"zephyr\", \"dateUpdated\": \"2026-10-26T16:08:54.724Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-82390\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-26T17:37:10.530Z\", \"dateReserved\": \"2026-08-28T21:11:44.241Z\", \"assignerOrgId\": \"e2e69745-5e70-4e92-8431-deb5529a81ad\", \"datePublished\": \"2026-10-26T16:08:54.724Z\", \"assignerShortName\": \"zephyr\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.