CVE-2026-89929 in Linux
الملخص
بحسب VulDB • 16/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
KVM: nVM: ضمان محاكاة أمر INVVPID على معالج فيزيائي (pCPU) الصحيح
عند محاكاة أمر INVVPID، ينفذ KVM الأمر INVVPID على المعالج الفيزيائي باستخدام vpid02 (بدلاً من VPID المُخصص لـ L1)، بعد إجراء بعض عمليات التحقق من صحة المدخلات. ومع ذلك، فمن الممكن أن يكون المعالج الفيزيائي الذي ينفذ عليه KVM أمر INVVPID مختلفًا عن المعالج الذي يعمل عليه L2.
على سبيل المثال، في السيناريو التالي: - يعمل L2 على المعالج #1 ويخرج إلى L1 (vmx->nested.vmcs02.cpu=1) - ينتقل L1 إلى المعالج #2 وينفذ أمر INVVPID - ينفذ KVM أمر INVVPID على المعالج #2 - يعود L1 للانتقال مرة أخرى إلى المعالج #1 ويشغل L2 (vmx->nested.vmcs02.cpu=1)
لا يتم إبطال إدخالات TLB في المعالج #1، لأن الأمر INVVPID نُفّذ على المعالج #2، ولم يشغّل vmcs02 أبدًا على معالج فيزيائي مختلف (أي أن دالة vmx_vcpu_load_vmcs() لن تطلب KVM_REQ_TLB_FLUSH).
تأكد من تنفيذ أمر INVVPID على نفس المعالج الفيزيائي الذي شغل عليه L2 آخر مرة، وإذا لم يكن كذلك، فانتقل إلى تعيين last_vpid=0 لتحفيز إبطال كامل لـ VPID في عملية الدخول التالية للآلة الافتراضية المتداخلة (Nested VM-Enter) (حيث سيكتشف KVM أن L1 تستخدم VPID مختلفًا لـ L2). وإذا انتهى الأمر بتشغيل L2 على معالج فيزيائي مختلف، فسيقوم KVM بإفراغ TLB على أي حال من خلال vmx_vcpu_load_vmcs().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.