CVE-2017-11671

What it actually does

The ix86_expand_builtin function in affected GCC versions emits instruction sequences for RDRAND and RDSEED intrinsics that overwrite the carry flag before the caller can test it, silently turning failed hardware RNG operations into apparent successes and returning uninitialized or low-entropy values.

Why it matters to the business

Applications compiled with the affected compiler versions may silently receive predictable or low-quality random numbers, weakening cryptographic keys, nonces, and tokens that rely on those intrinsics and increasing the chance of successful attacks against encryption, authentication, or session management.

How an attack unfolds

An attacker identifies software that was built with an affected GCC release and uses RDRAND/RDSEED intrinsics, then supplies inputs that trigger the flawed code path; because the carry flag is clobbered, the generated binary treats a failed hardware call as success and proceeds with whatever value is left in the destination register, allowing the attacker to observe or brute-force the resulting low-entropy output.

How to fix it

Upgrade to GCC 5.5 or 6.4 (or any later supported release) and rebuild all affected binaries that use the RDRAND or RDSEED intrinsics; where immediate rebuild is impossible, replace intrinsic usage with a software fallback that properly checks hardware status or uses a vetted library RNG.

How to confirm the fix worked

Recompile a test program that calls the intrinsics under the fixed compiler, disassemble the generated code, and confirm that the carry flag is tested immediately after the RDRAND/RDSEED instruction before any other flag-modifying operations occur; also verify that the binary no longer ships with the vulnerable pattern by searching for the known clobber sequence in object files.

Typical attack path

1. Compile or obtain a binary linked against code that calls RDRAND/RDSEED intrinsics using GCC 4.6–6.3
2. Deploy or execute the resulting binary on a system where the hardware RNG occasionally fails or returns status via the carry flag
3. Observe or force conditions that cause the intrinsic to be reached with a failed hardware operation
4. Consume the unvalidated random value in cryptographic or security-sensitive operations
5. Exploit the resulting predictability in keys, nonces, or tokens

How to detect it

Search build logs, package manifests, and binary metadata for compilation records that list GCC versions 4.6 through 6.3; inspect disassembled object files or core dumps for RDRAND/RDSEED sequences that lack an immediate carry-flag test; review application logs for unusually predictable random values or cryptographic failures that coincide with the use of affected binaries.

What your security team should do

• Inventory all build pipelines and third-party packages built with GCC 4.6–6.3 and prioritize rebuilds for any that link against cryptographic code
• Add compiler version checks to CI/CD pipelines so that builds using unsupported or vulnerable GCC releases are rejected
• Replace direct intrinsic calls with portable, status-checked RNG wrappers from a maintained library
• Monitor EPSS and KEV feeds for any future increase in exploitation of this class of compiler-induced RNG weakness