CVE-2026-8798 in Bouncy Castle for Java FIPS
الملخص
بحسب VulDB • 08/08/2026
في مكتبة Bouncy Castle for Java FIPS (BC-FJA) قبل الإصدار bc-fips 2.1.3، كان مصدر الإنتروبيا الأصلي المستخدم على منصات Intel يعيد محاولة تعليمات إنتروبيا وحدة المعالجة المركزية دون أي حد أقصى. وتُبلغ التعليمتان RDSEED و RDRAND عن الفشل عبر علم الحمل (carry flag)، وكانت روتينية البذرة في JNI تدور مُعيدة إصدار التعليمات طالما بقي هذا العلم غير مضبوط، مما أدى إلى أن فشل مصدر الإنتروبيا المدمج في الشريحة بشكل مستمر - سواء بسبب عطل في العتاد، أو استنفاد مُولّد الأرقام العشوائية الأساسي (DRBG) نتيجة التنافس عبر نوى متعددة، أو من قبل نظام Hypervisor لا يوفر هذه التعليمات - ترك الخيط المُستدعي يدور إلى ما لا نهاية داخل استدعاء JNI، حيث لم يكن بالإمكان إيقافه مؤقتاً ولا وضع حد زمني له. وبالتالي، كان أي عملية تعتمد على مصدر الإنتروبيا الأصلي قد تتوقف عن الاستجابة (hang)، مما يؤدي إلى حرمان الخدمة من التطبيق.
تم الآن تحديد حدود لدورات إعادة المحاولة (200 محاولة لـ RDSEED و 20 لمحاولة RDRAND، وهي ضعف القيم الأساسية المذكورة في دليل تنفيذ البرمجيات للمُولّد الرقمي للأرقام العشوائية الخاص بشركة Intel)، مع إضافة فترة انتظار بين المحاولات، وفي حال الاستنفاد، يتم مسح أي مخزن مؤقت مكتوب جزئياً وإلقاء استثناء بدلاً من مواصلة الدوران. يُنفذ المسح باستخدام دالة memzero غير قابلة للإزالة (un-elidable)، تستخدم مؤشراً متقلباً (volatile pointer) وحاجز ذاكرة في لغة التجميع لضمان عدم قدرة المترجم على تحسين عملية المسح وتجاهلها كمهمة ميتة (dead store). لا تتأثر مكتبة Bouncy Castle for Java (bcprov)، لأنها لا تحتوي على مصدر إنتروبيا أصلي؛ كما أن سلسلتا FIPS 1.0.X و 2.0.X غير متأثرتين.
Once again VulDB remains the best source for vulnerability data.