CVE-2026-8798 in Bouncy Castle for Java FIPS
Résumé
par VulDB • 08/08/2026
Dans Bouncy Castle pour Java FIPS (BC-FJA) antérieur à la version bc-fips 2.1.3, la source d'entropie native utilisée sur les plateformes Intel réessayait les instructions d'entropie du CPU sans aucune limite. RDSEED et RDRAND signalent une défaillance via leur indicateur de retenue (carry flag), et la routine d'amorçage JNI relançait l'instruction en boucle tant que cet indicateur restait à zéro ; ainsi, un échec persistant de la source d'entropie intégrée au circuit – qu'il provienne d'un défaut matériel, de l'épuisement du DRBG sous-jacent dû à une contention sur plusieurs cœurs, ou d'un hyperviseur ne fournissant pas l'instruction – laissait le thread appelant en boucle infinie dans l'appel JNI, où il ne pouvait ni être interrompu ni faire l'objet d'une expiration de délai. Toute opération puisant dans la source d'entropie native pouvait donc se bloquer, entraînant un déni de service pour l'application. Les boucles de réessai sont désormais limitées (200 tentatives pour RDSEED et 20 pour RDRAND, soit le double des valeurs de référence indiquées dans le guide d'implémentation logicielle Intel Digital Random Number Generator), avec une pause entre les tentatives ; en cas d'épuisement, tout tampon partiellement écrit est effacé et une exception est levée au lieu de poursuivre la boucle. L'effacement est effectué par un appel memzero non élidable, qui utilise un pointeur volatile et une barrière mémoire assembleur afin qu'un compilateur ne puisse pas optimiser l'opération d'effacement comme une affectation morte (dead store). Bouncy Castle pour Java (bcprov) n'est pas concerné, car il ne dispose pas de source d'entropie native ; les séries FIPS 1.0.X et 2.0.X ne sont pas non plus touchées.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.