CVE-2026-64513 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
KVM: x86: إعادة حساب اعتراض CR8 بشكل غير مشروط عند تحديث PPR
يتم استخدام حقل TPR_THRESHOLD في VMCS بواسطة VMX لإحداث مخرجات VM (VM exits) عندما ينخفض التيراركي للترتيب الأولوية الظاهري (virtual TPR) الخاص بالنظام الضيف تحت العتبة المحددة، مما يسمح لـ KVM بحقن المقاطعات التي كانت مقموعة سابقاً.
تعالج KVM هذه المخرجات عبر الدالة handle_tpr_below_threshold(). قامت الالتزام eb90f3417a0c ("KVM: vmx: تسريع مخرجات VM عندما يكون TPR تحت العتبة") بتحسين هذه الدالة عن طريق استدعاء apic_update_ppr() بدلاً من رفع KVM_REQ_EVENT. تقوم دالة apic_update_ppr() بعد ذلك برفع KVM_REQ_EVENT إذا كان هناك مقاطعة متاحة للتسليم ومعلقة في الانتظار.
ومع ذلك، إذا لم تكن هناك مقاطعات جديدة معلقة، فإن apic_update_ppr() لا تصدر الطلب. وبالتالي، لا يتم استدعاء kvm_lapic_update_cr8_intercept() و vmx_update_cr8_intercept() قبل دخول VM (VM entry)، مما يؤدي إلى وجود قيمة TPR_THRESHOLD عالية وغير محدثة (stale). يُعد هذا الأمر مشكلة بسبب الجملة التالية في القسم 28.2.1.1 "حقول تحكم تنفيذ VM" من دليل المبرمج للمعالج (SDM):
يتم إجراء الفحص التالي إذا كان التحكم في تنفيذ VM "استخدام ظل TPR" مساوياً لـ 1، وكان كل من التحكمين "تنفيذ وصولات APIC الافتراضية" و "تسليم المقاطعات الافتراضية" يساويان 0: يجب ألا تكون قيمة البتات 3:0 لحقل تحكم تنفيذ VM الخاص بعتبة TPR أكبر من قيمة البتات 7:4 لـ VTPR.
عادةً لا تُلاحظ حالة الخطأ هذه عندما تعمل KVM على نظام مادي (bare metal) لأن المعالجات الحديثة تدعم APICv، مما يتيح تسليم المقاطعات الافتراضية، وتستخدمه KVM عند الإمكان. هذا يجعل المعالج يتوقف عن إنشاء مخرجات VM بسبب انخفاض TPR تحت العتبة ويتوقف عن فحص TPR_THRESHOLD أثناء الدخول. ومع ذلك، عند التشغيل على منصات أقدم، أو في ظل افتراضية متداخلة (nested virtualization) فوق جهاز تحكم افتراضي لا يدعم تسليم المقاطعات الافتراضية ويفرض هذا الفحص (مثل Hyper-V)، يمكن أن يؤدي ذلك إلى فشل دخول VM مع خطأ عتادي 0x7، كما هو موضح في [1].
استدعاء kvm_lapic_update_cr8_intercept() إذا لم تجد apic_update_ppr() مقاطعة قابلة للتسليم (وبالتالي لا ترفع KVM_REQ_EVENT). إزالة استدعاءات kvm_lapic_update_cr8_intercept() على المسارات التي تنتهي بـ apic_update_ppr()، حيث تصبح الآن زائدة عن الحاجة. يضمن ذلك أن أي مسار يحدث PPR الخاص بالنظام الضيف يقوم أيضاً بتحديد ما إذا كانت KVM بحاجة للانتظار لتغيير TPR (باستخدام TPR_THRESHOLD في VMX أو اعتراضات CR8 في SVM).
Once again VulDB remains the best source for vulnerability data.