GHSA-FHVH-VW7H-9XF3: Cryptographic Signature Forgery via AVX2 Logic Error in libcrux-ml-dsa

The libcrux-ml-dsa library is a formally verified implementation of the Module-Lattice-based Digital Signature Algorithm (ML-DSA). This algorithm, previously known as Dilithium, forms a core component of post-quantum cryptographic standards defined in FIPS 204. The library implements various backends to optimize cryptographic operations across different hardware architectures. The vulnerability resides specifically within the performance-optimized AVX2 backend designed for x86_64 architectures.

The flaw occurs during the signature verification process, specifically within the use_hint function. This function executes Algorithm 40 of the FIPS 204 specification, which adjusts polynomial coefficients based on hint bits provided within the signature. The AVX2 implementation contains a logic error in its handling of low-order bits during this polynomial decomposition phase. This deviation from the specification constitutes a failure to properly verify cryptographic signatures (CWE-347).

The impact of this vulnerability is strictly constrained to the hardware architecture executing the AVX2 instructions. Portable or fallback implementations within the same library handle the mathematical operations correctly and reject the invalid signatures. Systems utilizing the vulnerable AVX2 backend may accept structurally invalid signatures, providing attackers with a mechanism to forge cryptographic trust.

The ML-DSA specification (FIPS 204) defines the use_hint(h, r) function to adjust polynomial coefficients based on a provided hint bit. The algorithm decomposes a coefficient r into a high-order component r1 and a low-order component r0. The hint bit h dictates the mathematical adjustment applied to the high-order component. This adjustment ensures that the signature verification process accurately reconstructs the required mathematical structures.

The specification mandates precise rules for this adjustment based on the value of the low-order bits. When the hint bit h equals 1 and r0 is strictly greater than 0, the algorithm computes (r1 + 1) mod m. When the hint bit h equals 1 and r0 is less than or equal to 0, the algorithm computes (r1 - 1) mod m. If the hint bit h equals 0, the output remains r1 without modification.

The logic error manifests in the AVX2 Single Instruction, Multiple Data (SIMD) implementation of these mathematical rules. The developers utilized the vec256_blendv_epi32 intrinsic to select the correct adjustment path based on the value of r0. The implementation incorrectly evaluated the condition for the negative adjustment path. It checked for r0 < 0 instead of the specified r0 <= 0.

Consequently, the AVX2 implementation fails to handle the edge case where r0 equals exactly zero. When r0 is 0 and the hint bit h is 1, the specification requires the function to return (r1 - 1) mod m. The vulnerable AVX2 implementation defaults to the positive path or the unmodified path, incorrectly returning r1. This mathematical divergence from the FIPS 204 standard causes the verifier to calculate an incorrect reconstructed polynomial.

The vulnerable code path utilizes specific SIMD intrinsics to optimize the mathematical operations across multiple data points simultaneously. The implementation constructs a bitmask to branch logic based on the sign of the low-order polynomial component r0. The vulnerability stems from the choice of intrinsic used to generate this comparative mask.

// Vulnerable Implementation (Conceptual AVX2 Logic)
// This mask strictly checks if r0 is greater than zero.
__m256i mask = _mm256_cmpgt_epi32(r0, zero);
 
// The blend selects plus_one_path if mask is true, minus_one_path otherwise.
// When r0 == 0, the mask is false, and the minus_one logic may be bypassed 
// or improperly blended depending on the exact intrinsic nesting.
__m256i result = _mm256_blendv_epi32(minus_one_path, plus_one_path, mask);

The issue arises because _mm256_cmpgt_epi32 only identifies values strictly greater than zero. The edge case where r0 equals zero causes the mask to evaluate as false. The resulting blend operation fails to route the zero value into the mathematical path required for the r0 <= 0 condition. The verifier thus applies the wrong mathematical operation to the polynomial.

// Patched Implementation (Conceptual AVX2 Logic)
// The fix ensures r0 == 0 is correctly categorized.
// Create a mask for r0 <= 0 by inverting a strictly greater-than check, 
// or by explicitly masking the zero condition.
__m256i mask_gt = _mm256_cmpgt_epi32(r0, zero);
 
// The corrected logic explicitly handles the zero boundary.
__m256i result = _mm256_blendv_epi32(corrected_minus_one_path, plus_one_path, mask_gt);

The patch modifies the mask generation sequence to strictly align with the r0 <= 0 requirement defined in FIPS 204. By correctly identifying the zero boundary condition, the SIMD pipeline routes the r0 = 0 coefficients through the (r1 - 1) mod m computation path. This modification restores cryptographic parity between the AVX2 backend and the formally verified portable implementation.

Exploiting this vulnerability requires an attacker to construct a specific mathematical payload within a digital signature. The attacker must target the polynomial reconstruction phase of the ML-DSA algorithm. The primary objective is to force the verifier's internal state into the exact edge case where the low-order bit component evaluates to zero.

The attacker analyzes the public key and crafts a message-signature pair that satisfies the prerequisite mathematical conditions. During the verification phase, the forged signature must yield internal polynomial values where r0 = 0 and the hint bit h = 1. Achieving this specific state requires deep mathematical manipulation of the lattice structures defining the ML-DSA signature scheme.

When the vulnerable AVX2 verifier processes this crafted signature, it evaluates the use_hint function using the flawed SIMD logic. Because r0 equals zero, the verifier computes an incorrect value for the reconstructed polynomial. The attacker engineers the forged signature such that this specific mathematical error causes the overall verification equation to balance. The verifier concludes that the signature is valid, bypassing the cryptographic integrity checks.

The exploit strictly depends on the hardware environment executing the verification process. The attacker cannot compel the target to use the AVX2 backend remotely. The target system must natively support the AVX2 instruction set and must be compiled to utilize the specific libcrux-ml-dsa optimized paths. If the target system falls back to the portable implementation, the forged signature is correctly rejected.

The vulnerability allows unauthenticated attackers to perform cryptographic signature spoofing against affected systems. Successful exploitation compromises the fundamental trust model of the digital signature algorithm. Attackers can forge identities, authorize unauthorized transactions, or bypass access controls that rely on ML-DSA cryptographic proofs.

The vulnerability is tracked under CVSS v4.0 with a High severity base score of 8.2 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N). The attack vector is strictly network-based, requiring no authentication or user interaction. The high integrity impact reflects the complete failure of the signature validation mechanism for specific crafted inputs.

The Attack Requirements (AT:P) metric is evaluated as Present due to the strict hardware prerequisites. The vulnerability does not manifest on architectures lacking AVX2 extensions or on systems explicitly compiled to utilize the portable Rust implementation. This hardware dependency restricts the exploitable surface area but remains highly relevant for modern x86_64 server environments executing cryptographic workloads.

Implementations of post-quantum cryptography are actively being integrated into critical infrastructure, secure boot mechanisms, and identity verification protocols. A fundamental flaw in the signature verification primitive exposes these early adopters to severe supply chain and authentication risks. Organizations migrating to FIPS 204 compliance using libcrux-ml-dsa face immediate threats if deploying the unpatched library on modern x86_64 hardware.

Organizations utilizing the libcrux-ml-dsa library must immediately upgrade their dependencies to version 0.0.9 or later. The patched version resolves the logic error within the AVX2 backend, ensuring the SIMD operations correctly align with the mathematical requirements of the FIPS 204 specification. The upgrade requires recompilation of the dependent applications to statically link the corrected cryptographic primitives.

Administrators operating in environments where immediate patching is impossible can implement a software-level workaround. The vulnerability can be mitigated by explicitly disabling the AVX2 backend within the library's configuration. Forcing the application to utilize the portable, formally verified Rust implementation bypasses the flawed SIMD logic entirely. The portable implementation correctly handles the edge case and rejects forged signatures.

> [!NOTE] > Disabling the AVX2 backend incurs a substantial performance penalty. Cryptographic operations, specifically signature verification routines, will execute significantly slower due to the absence of SIMD hardware optimizations.

Security teams should validate their mitigation efforts by implementing rigorous unit testing. The Wycheproof cryptographic testing framework includes specific test vectors designed to exercise the use_hint edge case. Executing these test cases against the compiled application verifies that the environment correctly rejects signatures exhibiting the mathematical anomalies associated with this vulnerability.