CVE-2026-99120 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
KVM: x86/mmu: التعامل مع تعيين bit SS في رموز الخروج من #NPF (Page Fault غير موجود)
عند تشغيل Hyper-V على نظام Windows 11، يلاحظ KVM أن bit SS مُعيّن في أكواد أخطاء faults الصفحات المتداخلة (nested page fault error codes) المُنتَجة للـ NPT المظلل. وتكون وثائق AMD غامضة بشأن متى يتم تعيين SS، بما في ذلك ما إذا كان يمكن تعيينه عندما لا يكون SupervisorShadowStackEn (bit 6) مُعيّناً في حقل MISC_CTL الخاص بـ VMCB.
ومع ذلك، فإن bit SS غير المتوقع يسبب وصولات خارج النطاق (out of bounds accesses) في دالة permission_fault()، وتظهر إما كتحذيرات (WARNs) أو تقارير UBSAN:
kernel: UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27 kernel: index 34 is out of range for type 'u16 [16]'
(في هذه الحالة، رمز خطأ fault الصفحة هو 34*2=0x44، أي SS|U؛ ويظهر التقرير أيضاً حدوث SS|U|W). تم إصلاح معالجة أكواد الأخطاء غير المعروفة عن طريق إزالة bit SS و (مع تحذير) أي bits أخرى ليست ضمن تلك التي تتوقعها دالة permission_fault() لاستلامها.
في الوقت نفسه، نظراً لعدم اليقين حول متى يحدد العتاد تعيين SS، اتبع سلوك المعالج عند بناء رمز الخطأ الخاص بالـ fault، واحتفظ بـ bit SS كما هو مُمرّر إلى FNAME(walk_addr_generic). وعلى الرغم من أن السلوك مدهش، فهناك احتمال أن يتوقعه Hyper-V (فـ Hyper-V لا يفعّل CET إلا إذا وجد MBEC/GMET!)، لذا تم الاحتفاظ بالمعلومات عند عكس الـ fault إلى L1 بدلاً من تجاهلها بشكل غير مشروط.
أظهر التحليل الثنائي (Bisection) أن هذا بدأ يحدث مع commit 687ee95c1b6d ("KVM: nSVM: enable GMET for guests")، على الرغم من أن SHSTK كان متاحاً للضيوف منذ Linux 6.18. ومع ذلك، ليس هذا بسبب أن bit 1 في MISC_CTL (GMET) يفعّل بطريقة ما الإبلاغ عن bit SS؛ بل هو ببساطة أن Hyper-V لا يستخدم CET إلا إذا كان GMET موجوداً أيضاً. ويمكن إعادة إنتاج التحذير حتى مع gmet=0، من خلال بعض التعديلات على اختبار cet.c الخاص بـ kvm-unit-tests لضمان حدوث fault صفحة عند أول وصول إلى المكدس الظللي (shadow stack).
If you want to get best quality of vulnerability data, you may have to visit VulDB.