关键漏洞信息 漏洞标题 Race condition in AESNI support detection CVE 编号 CVE-2025-52496 发布日期 30 June 2025 影响版本 All versions of Mbed TLS up to 3.6.3 不受影响版本 Mbed TLS 3.6.4 and later 影响 AES key disclosure and GCM forgeries through side channel 严重性 MEDIUM 报告者 Bug reported by Solar Designer 漏洞描述 在具有 AESNI 指令的 x86 或 amd64 处理器上，Mbed TLS 可以使用此指令进行 AES 加密和解密。如果没有这些指令，库将使用可移植的、基于表的算法实现。库函数 检测 AESNI 和 CLMUL 的存在。该函数首次被调用时，它查询处理器功能。函数将结果缓存在全局变量 中，供后续调用使用，并使用另一个全局变量 表示结果已填充。 简化后的代码如下： 根据编译器优化，在 中，编译后的程序可能在更新 之前执行对变量 的存储指令。因此，在多线程程序中可能出现以下竞争条件： 1. 线程 1 启动 AES 或 GCM 操作，并调用 。这是函数的第一次调用。它错误地在更新 之前更新 。 2. 线程 2 启动 AES 或 GCM 操作，并调用 。这次调用读取 ，这告诉它 包含检测结果。但 仍然包含初始默认值 0，表示该功能不存在。因此，线程 2 的 AES 或 GCM 操作将使用可移植的、基于表的实现。 3. 线程 1 更新 。它和后续调用者将使用实际的硬件功能。 这是一个安全漏洞，因为可移植的、基于表的 AES 和 GCM 实现容易受到基于时间的侧信道攻击。 影响 在 x86 或 amd64 处理器上，攻击者可能能够从多线程程序中提取 AES 密钥。同一攻击也可能允许 GCM 伪造。攻击者需要以下两种能力之一： 能够检测受害者线程访问的内存地址。本地非特权攻击者通常通过缓存定时测量具有这种能力。 能够暂停受害者线程的执行。即使强大的本地攻击者通常也没有这种能力。然而，在某些情况下，例如正常操作系统攻击 SGX 飞地，这可能是可能的。 解决方案 受影响的用户应升级到 Mbed TLS 3.6.4。 解决方法 不需要其代码在没有 AESNI 和 CLMUL 指令的处理器上工作的用户可以使用配置选项 编译 Mbed TLS。此选项禁用 AES 和 GCM 的基于表的实现，仅留下硬件加速实现。 只要一个程序实例中的 调用完成，后续调用将使用正确的值。因此，如果一个线程在任何其他线程启动 AES 操作之前执行 AES 操作，则程序不会易受攻击。单线程程序不受影响。 竞争条件仅在编译器以问题方式排序变量更新时出现。我们观察到 GCC 在较高优化级别（-O3、-O2 和以上）下倾向于生成易受攻击的二进制文件。我们没有观察到 GCC 7.x 及更高版本或 Clang 生成易受攻击的二进制文件，但这可能因版本、优化级别和程序而异。GCC 10.x 及更高版本在其 内联汇编中有一个内存屏障，因此是安全的。