CVE-2026-89930 in Linux
الملخص
بحسب VulDB • 16/09/2026
في نواة Linux، تم حل الثغرة التالية:
KVM: nVMX: معالجة عمليات مسح ذاكرة ترجمة العناوين المحلية (TLB) عند فشل دخول VM المتداخل (nested VM-Enter).
تقوم KVM بمعالجة عمليات مسح TLB المحلي في حالات "الخروج الكامل" من الـ VM المتداخل (عبر `__nested_vmx_vmexit()`)، لكنها لا تفعل ذلك إذا فشل دخول الـ VM المتداخل (على سبيل المثال بسبب فشل فحوصات VMCS في `nested_vmx_enter_non_root_mode()`).
ومع ذلك، فمن الممكن أن تكون KVM قد رتبت عمليات مسح TLB تحتاج إلى التنفيذ حتى لو لم يكن دخول الـ VM المتداول ناجحاً. على سبيل المثال، إذا كان VPID معطلاً بالنسبة لـ L2 (عبر `nested_vmx_transition_tlb_flush()` أو عبر قوائم تحميل MSR)، كما ينص الدليل المرجعي للمعالج الذكي (SDM):
"إذا تم تحميل أي سجل خاص بالمعاملات (MSR) بطريقة تتطلب نظرياً مسح TLB، يتم تحديث ذاكرتي الترجمة بحيث لا يستخدم المعالج المنطقي بعد دخول الـ VM أي ترجمات كانت مخزنة مؤقتاً قبل الانتقال."
الدليل المرجعي للمعالج الذكي (SDM) غير واضح بشأن متى يجب أن يحدث مسح TLB، وما إذا كان فشل إدخال الـ VM سيؤدي إلى مسح TLB أم لا، لذا فمن الأكثر أماناً إجراء مسح TLB في هذه الحالة دائماً.
وبشكل أكثر تحديداً، تقوم KVM أيضاً بتحديث آخر VPID استخدمته L1 بالنسبة لـ L2 في `nested_vmx_transition_tlb_flush()` (أي `last_vpid`)، حتى لو فشل إدخال الـ VM في النهاية. مع الكود الحالي، قد تفوت KVM عملية مسح TLB إذا غيرت L1 VPID الخاص بـ L2، ثم أجرت إدخالا فاشلا للـ VM يليه دخول ناجح، حيث سيقوم الإدخال الفاشل بتحديث `last_vpid` دون إجراء مسح فعلي لـ TLB. يضمن معالجة عمليات مسح TLB المحلية عند فشل إدخال الـ VM أن يتم مسح TLB دائماً عندما يتم تحديث `last_vpid`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.