Mbed TLS CVE-2025-52496: AESNI Race Condition Leading to Side-Channel Key Disclosure

Critical Vulnerability Information Vulnerability Title Race condition in AESNI support detection CVE Number CVE-2025-52496 Release Date 30 June 2025 Affected Versions All versions of Mbed TLS up to 3.6.3 Unaffected Versions Mbed TLS 3.6.4 and later Impact AES key disclosure and GCM forgeries through side channel Severity MEDIUM Reporter Bug reported by Solar Designer Vulnerability Description On x86 or amd64 processors with AESNI instructions, Mbed TLS can use these instructions for AES encryption and decryption. If these instructions are not available, the library falls back to a portable, table-based implementation. The library function detects the presence of AESNI and CLMUL. When called for the first time, this function queries the processor features. It caches the result in a global variable for subsequent calls, and uses another global variable to indicate that the result has been populated. The simplified code is as follows: Due to compiler optimizations, in , the compiled program may store the value of before updating . This can lead to a race condition in multithreaded programs: 1. Thread 1 starts an AES or GCM operation and calls . This is the first call to the function. It incorrectly updates before updating . 2. Thread 2 starts an AES or GCM operation and calls . This call reads , which indicates that contains the detection result. However, still holds its initial default value of 0, indicating the feature is not present. As a result, Thread 2's AES or GCM operation will use the portable, table-based implementation. 3. Thread 1 updates . It and subsequent callers will use the actual hardware capabilities. This is a security vulnerability because the portable, table-based AES and GCM implementations are susceptible to timing-based side-channel attacks. Impact On x86 or amd64 processors, an attacker may be able to extract AES keys from multithreaded programs. The same attack may also allow GCM forgeries. The attacker must have one of the following two capabilities: The ability to detect memory addresses accessed by the victim thread. Local, non-privileged attackers typically achieve this via cache timing measurements. The ability to pause the execution of the victim thread. Even powerful local attackers usually lack this capability. However, in certain scenarios—such as normal OS attacks against SGX enclaves—this may be possible. Solution Affected users should upgrade to Mbed TLS 3.6.4. Workaround Users who do not need their code to run on processors without AESNI and CLMUL instructions can compile Mbed TLS with the configuration option . This option disables the table-based implementations for AES and GCM, leaving only the hardware-accelerated implementations. As long as the call in one program instance completes, subsequent calls will use the correct value. Therefore, if a thread performs an AES operation before any other thread starts an AES operation, the program is not vulnerable. Single-threaded programs are unaffected. The race condition only occurs when the compiler orders variable updates in a problematic way. We observed that GCC tends to generate vulnerable binaries at higher optimization levels (-O3, -O2, and above). We did not observe GCC 7.x and later or Clang generating vulnerable binaries, but this may vary by version, optimization level, and program. GCC 10.x and later include a memory barrier in their inline assembly, making them secure.

Goal Reached Thanks to every supporter — we hit 100%!

Mbed TLS CVE-2025-52496: AESNI Race Condition Leading to Side-Channel Key Disclosure

More from this source