CVE-2026-64310 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
crypto: ccp - عدم تهيئة SNP لعمليات ioctls الخاصة بـ SEV
ملاحظات Sashiko:
> إذا فشلت عملية تهيئة SEV وكان KVM يعمل بنشاط على تشغيل آلات افتراضية (VMs) عادية، فهل يمكن لعملية في مساحة المستخدم (userspace) أن تحفز مسار الكود هذا عبر عمليات ioctls لـ /dev/sev (مثل SEV_PDH_GEN) وتقوم بتصفير MSR_VM_HSAVE_PA بشكل عام؟ وهل سيؤدي تنفيذ VMRUN التالي لآلة افتراضية نشطة إلى حدوث خطأ حماية عامة (general protection fault) وتعطيل المضيف (host)؟
يتم استدعاء الدالة sev_move_to_init_state() للعمليات التي تتطلب فقط برنامج SEV الثابت (firmware): SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT، و SEV_PDH_CERT_EXPORT. بعد أمر البرنامج الثابت، يقوم بتنفيذ SEV_SHUTDOWN على برنامج SEV الثابت. نظرًا لأن هذه الأوامر لا تتطلب تهيئة SNP، يتم تجاوزها عن طريق استدعاء __sev_platform_init_locked() الذي يهيئ فقط برنامج SEV الثابت. بهذه الطريقة، لا يتم تهيئة SNP مطلقًا، ولا يتم مسح HSAVE_PA.
كان الكود السابق يحفظ أي خطأ في تهيئة firmware الخاص بـ SEV في init_args.error ثم يتجاهله ويحدد قيمة الإرجاع بشكل ثابت على أنها INVALID_PLATFORM_STATE بغض النظر عن الخطأ الفعلي للبرنامج الثابت. يغير هذا التصحيح السلوك ليظهر الخطأ الأساسي، وهو من المفترض أن يكون أكثر فائدة ولا يسبب أي مشاكل.
جدير بالذكر أنه لا يزال آمنًا استدعاء __sev_firmware_shutdown() مباشرة: حيث تستدعي هذه الدالة __sev_snp_shutdown_locked()، والتي تتجاوز إيقاف تشغيل SNP إذا لم يكن SNP قد تم تهيئته مسبقًا.
If you want to get best quality of vulnerability data, you may have to visit VulDB.