CVE-2026-93160 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: atmel-ecc - reject hardware ECDH without a public key
The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm.
atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel's Atmel Elliptic Curve Cryptography (ECC) driver, specifically within the hardware ECDH implementation, represents a critical flaw in state management and cryptographic context isolation. The core issue resides in the function atmel_ecdh_compute_shared_secret(), which is responsible for performing the actual elliptic curve Diffie-Hellman key exchange operation using hardware acceleration on Atmel microcontrollers. This function relies on a private key stored within the device's secure storage to compute the shared secret with a peer's public key. However, the driver architecture caches the corresponding public key only after atmel_ecdh_set_secret() has successfully generated that specific private key for the current transformation context or tfm instance.
The technical flaw arises from an inconsistency in validation logic between these two functions. While atmel_ecdh_generate_public_key(), which is invoked during the setup phase, correctly rejects requests if no public key is cached—thereby ensuring a valid pair exists—the compute function lacks this same safeguard. Consequently, it is possible for atmel_ecdh_compute_shared_secret() to be called with a private key that was generated in a previous tfm context or under different parameters, rather than the one intended for the current cryptographic operation. This mismatch occurs because the driver does not verify that the cached public key corresponds to the private key currently being used by the device hardware before proceeding with the computation.
From an operational impact perspective, this vulnerability can lead to severe security consequences including information disclosure and authentication bypasses. If a shared secret is computed using a stale or incorrect private key, the resulting cryptographic material will not match what the communicating party expects based on their own public key exchange. In protocols relying on ECDH for session key establishment, such as TLS or IPsec, this mismatch can cause connection failures that might be exploited to trigger denial of service conditions through repeated failed handshakes. More critically, in scenarios where side-channel analysis is feasible or if the implementation allows fallback mechanisms, an attacker could potentially manipulate the context to force the use of a known private key from a previous session. This would allow the derivation of shared secrets that are predictable or already compromised, effectively breaking the confidentiality and integrity guarantees provided by the cryptographic protocol.
This flaw aligns with CWE-20 Improper Input Validation, as the system fails to adequately validate the state consistency between the private key in use and its corresponding public key cache before performing a sensitive operation. It also relates to CWE-367 Time-of-check to Time-of-use (TOCTOU) race conditions or logic errors regarding context isolation, where the assumption that the cached data remains valid for the current execution flow is violated due to improper state tracking across different tfm instances. Furthermore, in terms of MITRE ATT&CK mapping, this vulnerability facilitates techniques associated with T1504 Weak or Unprotected Credentials and potentially aids in lateral movement if compromised session keys are used to impersonate legitimate peers within a network infrastructure.
To mitigate this risk, the primary remediation is the application of the patch that adds the same public key cache validation check found in atmel_ecdh_generate_public_key() directly into atmel_ecdh_compute_shared_secret(). This ensures that the hardware will only proceed with ECDH computations if there is a verified, up-to-date cached public key corresponding to the private key currently loaded. Beyond this specific code fix, system administrators and developers should ensure that all affected kernel versions are updated immediately. Additionally, implementing strict context isolation in cryptographic drivers by resetting or invalidating caches upon tfm destruction can prevent residual state leakage between different cryptographic operations. Regular auditing of hardware crypto driver implementations for similar state management inconsistencies is recommended to maintain robust security posture across embedded Linux environments utilizing Atmel secure elements.