Bouncy Castle BC-FJA Cryptographic Engine Flaws

Unbounded retry loops in BC-FJA's JNI native entropy layer cause calling threads to hang indefinitely when Intel RDSEED or RDRAND instructions persistently fail, producing a non-interruptible thread-level denial of service in any Java FIPS application backed by bc-fips 2.1.x before 2.1.3. The affected JNI seeding routine re-issues the CPU entropy instruction without any iteration limit whenever the carry flag signals failure - a condition reproducible by hardware entropy source faults, DRBG exhaustion under heavy multi-core contention, or hypervisors that do not forward these Intel instructions to guest VMs. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the conditions are routinely present in virtualized environments where hypervisors commonly withhold RDRAND/RDSEED forwarding, making this a realistic operational risk for enterprise Java FIPS deployments in cloud or VM-based infrastructure.

Cryptographic key material in Bouncy Castle for Java FIPS (BC-FJA) persists in the JVM heap far beyond its intended lifetime on Java 12 and later runtimes because the library's zeroisation scheme relies on Object.finalize(), a mechanism progressively de-emphasized since Java 9 and deprecated for removal in Java 18. Under load, the single finalizer thread cannot retire pending objects as fast as they are allocated, causing the queue to grow without bound - resulting in an OutOfMemoryError that crashes the application and defeating the cryptographic hygiene goal of prompt key zeroisation. No public exploit is identified at time of analysis; however, any network-accessible application built on BC-FJA prior to the fixed versions is exposed to both a remotely triggerable denial-of-service and prolonged in-memory residence of sensitive key material.