This CVE fixes an infinite loop in BC-FJA's entropy acquisition that would hang indefinitely when RDRAND/RDSEED failed to return entropy. The patch adds a bounded retry (200 iterations with 20-microsecond delays) and throws EntropySourceException when bounds are exhausted, with volatile memory zeroing to clear sensitive state.
The critical insight here is that the fix changes the failure mode rather than eliminating it. Previously, your application would hang silently in SecureRandom initialization—a known failure that many deployments had already built workarounds around (timeout threads, watchdog restarts, or simply ignoring it as rare). Now, BC-FJA throws an EntropySourceException and your application crashes unless you handle it.
What you should do now: Audit every BC-FJA deployment for entropy failure handling. Specifically, trace your call stack from wherever SecureRandom gets instantiated and determine whether EntropySourceException is caught anywhere in the initialization path. If not, your application will terminate abruptly when entropy is unavailable—which is a real scenario in virtualized environments where hypervisors deliberately disable RDRAND, under heavy cross-core DRBG contention, or when hardware fails.
The secondary risk: developers catching this exception may fall back to java.util.Random or other userspace PRNGs as the path of least resistance. This creates a downgrade attack surface worse than the original hang—weak entropy at runtime is more dangerous than a diagnosed hang.
For FIPS-certified deployments, note that the fix introduces a documented-but-unhandled failure mode into a validated module. Your entropy failure contract with the module just changed, and if your certification boundary includes SecureRandom initialization behavior, you may need to re-evaluate whether EntropySourceException handling falls within your certified scope.