CVE-2024-50382: Botan GHASH AES-GCM Information Disclosure

CVE-2024-50382 Overview

CVE-2024-50382 affects Botan versions before 3.6.0 when compiled with certain LLVM releases. The vulnerability introduces a compiler-induced, secret-dependent control flow in the GHASH implementation used by AES-GCM. Instead of emitting a constant-time XOR with carry, the compiler generates a branch dependent on secret key material. Researchers observed the issue with Clang from LLVM 15 on RISC-V. The flaw is classified under [CWE-203] (Observable Discrepancy) and creates a timing side channel that can leak sensitive information from cryptographic operations.

Critical Impact
Attackers with the ability to observe execution timing may recover secret-dependent data processed by Botan's AES-GCM GHASH routine.

Affected Products

Botan cryptographic library versions before 3.6.0
Botan builds compiled with Clang/LLVM 15 targeting RISC-V
Applications embedding vulnerable Botan builds for AES-GCM operations

Discovery Timeline

2024-10-23 - CVE-2024-50382 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-50382

Vulnerability Analysis

The defect lives in lib/utils/ghash/ghash.cpp, which implements the GHASH universal hash used in AES-GCM authenticated encryption. The original source code multiplies the reduction polynomial R by the least significant bit of H1 to produce a carry value. This expression is written to be constant-time, avoiding branches on secret data.

However, when compiled with Clang from LLVM 15 targeting RISC-V, the optimizer rewrites the multiplication into a conditional branch. The branch tests a bit derived from the secret hash subkey H. An attacker observing execution timing, cache behavior, or micro-architectural signals can infer the value of that bit across repeated invocations.

Over enough measurements, an attacker can reconstruct the GHASH subkey and undermine the authenticity guarantees of AES-GCM. The vulnerability requires high attack complexity because it depends on both the compiler version and the target architecture.

Root Cause

The root cause is not a source-level flaw but a compiler transformation that violates the constant-time contract. Botan's authors relied on arithmetic constructs to avoid branches. LLVM 15's RISC-V backend recognized the pattern and substituted a branch as a supposed optimization. The fix strengthens the value barrier so the compiler cannot lower the operation into secret-dependent control flow.

Attack Vector

Exploitation requires the attacker to measure precise timing or micro-architectural side effects of AES-GCM operations performed by a target that uses a vulnerable Botan build. Suitable scenarios include co-located tenants on shared hardware and network attackers with high-resolution timing capability against services performing many GCM operations with a stable key.

// Source: https://github.com/randombit/botan/commit/53b0cfde580e86b03d0d27a488b6c134f662e957
// Patch in src/lib/utils/ghash/ghash.cpp
         m_HM[4 * j + 2 * i + 1] = H1;
 
         // GCM's bit ops are reversed so we carry out of the bottom
-         const uint64_t carry = R * (H1 & 1);
+         const uint64_t carry = CT::Mask<uint64_t>::expand(H1 & 1).if_set_return(R);
         H1 = (H1 >> 1) | (H0 << 63);
         H0 = (H0 >> 1) ^ carry;
      }

The patch replaces the arithmetic multiplication with an explicit constant-time mask helper, CT::Mask<uint64_t>::expand(...).if_set_return(R). This construct interposes a value barrier that prevents the compiler from lowering the expression to a branch.

Detection Methods for CVE-2024-50382

Indicators of Compromise

No file-based indicators exist because exploitation is passive observation of timing signals.
Unusually high-frequency AES-GCM operations from a single client against a service using Botan may indicate side-channel probing.
Co-tenant workloads performing sustained cache or timing measurements against cryptographic processes warrant review.

Detection Strategies

Inventory applications and containers linking against Botan and identify versions earlier than 3.6.0.
Correlate build toolchain metadata to flag binaries produced with Clang/LLVM 15 on RISC-V targets.
Disassemble the compiled ghash.cpp object and confirm the presence of a branch instruction in the GHASH carry path.

Monitoring Recommendations

Instrument cryptographic services to log unexpected volumes of AES-GCM operations from single sources.
Track process-level performance counters for anomalous cache-miss patterns on hosts performing TLS or bulk GCM decryption.
Alert on new deployments of Botan below 3.6.0 through software composition analysis in CI/CD pipelines.

How to Mitigate CVE-2024-50382

Immediate Actions Required

Upgrade Botan to version 3.6.0 or later across all builds and container images.
Rebuild affected binaries after upgrading and redeploy services that perform AES-GCM operations.
Rotate any long-lived AES-GCM keys used by services that ran vulnerable builds on RISC-V with Clang/LLVM 15.

Patch Information

The upstream fix is available in the Botan repository at commit 53b0cfde580e86b03d0d27a488b6c134f662e957, which adds constant-time value barriers to ghash.cpp and donna128.h. Full changes are visible in the Botan 3.5.0 to 3.6.0 comparison. Background on the compiler-induced side channel is documented in the ArXiv research paper.

Workarounds

Rebuild Botan with a compiler version and target combination not known to introduce the branch, avoiding Clang/LLVM 15 on RISC-V.
Prefer AES-GCM implementations backed by hardware instructions such as AES-NI or ARMv8 crypto extensions where the vulnerable software path is bypassed.
Restrict untrusted co-tenancy on hosts running services that perform AES-GCM with a static key until upgraded.

bash

# Verify installed Botan version and rebuild against 3.6.0 or later
botan version
git clone https://github.com/randombit/botan.git
cd botan
git checkout 3.6.0
./configure.py --cc=clang
make -j"$(nproc)" && sudo make install