CVE-2026-8798: CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop') in Legion of the Bouncy Castle Inc. BC-FJA
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20 for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store. Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X FIPS series are not affected.
AI Analysis
Technical Summary
In BC-FJA versions before 2.1.3, the native entropy source on Intel platforms used unbounded retry loops for CPU entropy instructions RDSEED and RDRAND. These instructions signal failure via the carry flag, and the JNI seeding routine would continuously retry as long as the flag indicated failure, causing an infinite loop if the entropy source failed persistently. This could be due to hardware faults, DRBG exhaustion, or hypervisor limitations. The infinite loop leads to a hang in any operation drawing entropy from the native source, resulting in denial of service. The fix implemented in 2.1.3 bounds retries (200 attempts for RDSEED, 20 for RDRAND), pauses between attempts, clears any partially written buffer securely, and throws an exception on exhaustion to prevent indefinite spinning. The Bouncy Castle Java provider (bcprov) and earlier FIPS series 1.0.X and 2.0.X are not affected.
Potential Impact
The vulnerability can cause denial of service by hanging the calling thread indefinitely when the native entropy source on Intel platforms fails persistently. This affects any operation relying on native entropy in BC-FJA version 2.1.0, potentially impacting cryptographic operations that require entropy. There is no indication of code execution or data compromise, but availability is impacted.
Mitigation Recommendations
A fix is available in Bouncy Castle for Java FIPS version 2.1.3, which bounds the retry loops for RDSEED and RDRAND instructions and throws an exception on failure instead of looping indefinitely. Users should upgrade to version 2.1.3 or later to remediate this issue. No other mitigations are indicated.
CVE-2026-8798: CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop') in Legion of the Bouncy Castle Inc. BC-FJA
Description
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20 for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store. Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X FIPS series are not affected.
CVSS v4.0
Score 8.7high
Affected software
Legion of the Bouncy Castle Inc.
BC-FJA
pkg:maven/org.bouncycastle/bc-fipsRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
In BC-FJA versions before 2.1.3, the native entropy source on Intel platforms used unbounded retry loops for CPU entropy instructions RDSEED and RDRAND. These instructions signal failure via the carry flag, and the JNI seeding routine would continuously retry as long as the flag indicated failure, causing an infinite loop if the entropy source failed persistently. This could be due to hardware faults, DRBG exhaustion, or hypervisor limitations. The infinite loop leads to a hang in any operation drawing entropy from the native source, resulting in denial of service. The fix implemented in 2.1.3 bounds retries (200 attempts for RDSEED, 20 for RDRAND), pauses between attempts, clears any partially written buffer securely, and throws an exception on exhaustion to prevent indefinite spinning. The Bouncy Castle Java provider (bcprov) and earlier FIPS series 1.0.X and 2.0.X are not affected.
Potential Impact
The vulnerability can cause denial of service by hanging the calling thread indefinitely when the native entropy source on Intel platforms fails persistently. This affects any operation relying on native entropy in BC-FJA version 2.1.0, potentially impacting cryptographic operations that require entropy. There is no indication of code execution or data compromise, but availability is impacted.
Mitigation Recommendations
A fix is available in Bouncy Castle for Java FIPS version 2.1.3, which bounds the retry loops for RDSEED and RDRAND instructions and throws an exception on failure instead of looping indefinitely. Users should upgrade to version 2.1.3 or later to remediate this issue. No other mitigations are indicated.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- bcorg
- Date Reserved
- 2026-05-18T01:17:23.058Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6a767ecdbf8831d53990b9dc
Added to database: 08/08/2026, 00:56:45 UTC
Last enriched: 08/15/2026, 15:14:43 UTC
Last updated: 09/22/2026, 01:54:34 UTC
Views: 79
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.