| البند | التفاصيل |
|---|---|
| نوع الثغرة | Use-After-Free / Race Condition في الذاكرة تؤدي إلى هروب من الجهاز الافتراضي إلى المضيف (VM Escape) |
| المُعرِّف | CVE-2026-53359 — ولها ثغرة مصاحبة CVE-2026-46113 |
| الاسم المتداول | Januscape |
| الأنظمة المتأثرة | Linux KVM على معالجات Intel (VMX/EPT) وAMD (SVM/NPT) على حد سواء |
| عمر الثغرة | نحو 16 عامًا (الكود المسبب موجود منذ أغسطس 2010) |
| حالة الإصلاح | تم إصلاحها في نواة لينكس الرئيسية ووصلت إلى الفروع المستقرة في 4 يوليو 2026 |
| حالة الاستغلال | يوجد إثبات مفهوم علني يُسقط المضيف (Host Crash)؛ ويُزعم وجود استغلال كامل لتنفيذ أوامر بصلاحية root لم يُنشر بعد |
مقدمة
في 6 يوليو 2026 كشف الباحث الأمني Hyunwoo Kim (المعروف باسم v4bel) عن ثغرة أطلق عليها اسم Januscape، وهي عيب في الطريقة التي تدير بها نواة لينكس أجهزة KVM الافتراضية، سُجِّلت تحت المعرف CVE-2026-53359. ما يجعل هذه الثغرة لافتة ليس فقط قدرتها على السماح لجهاز افتراضي بالهروب إلى النظام المضيف الذي يستضيفه، بل أن الكود المسبب لها موجود في نواة لينكس منذ عام 2010 تقريبًا، أي أن كل نواة لينكس صدرت خلال الستة عشر عامًا الماضية تقريبًا كانت تحمل هذا العيب دون أن يلاحظه أحد.
KVM (اختصار Kernel-based Virtual Machine) هو المكوّن المدمج في نواة لينكس الذي يحوّل الجهاز إلى منصة استضافة أجهزة افتراضية (Hypervisor)، وهو ما يعتمد عليه عمليًا معظم مزودي الحوسبة السحابية وأنظمة مثل Proxmox وOpenStack ومنصات الاستضافة الافتراضية. و"هروب الجهاز الافتراضي" (VM Escape) يعني أن برنامجًا يعمل داخل جهاز افتراضي واحد يتمكن من كسر العزل المفترض ويصل إلى موارد النظام المضيف نفسه أو الأجهزة الافتراضية الأخرى المستضافة عليه — وهو أخطر سيناريو ممكن في البيئات السحابية متعددة المستأجرين، لأن المستأجرين المختلفين يفترض أنهم معزولون تمامًا عن بعضهم. ثغرة تمكّن من هذا العزل تعني عمليًا أن أي عميل يستأجر جهازًا افتراضيًا واحدًا فقط قد يتمكن من التأثير على جميع العملاء الآخرين المشتركين معه على نفس الخادم الفيزيائي.
الآلية التقنية: ما هو الـ Shadow MMU وكيف انكسر العزل؟
لفهم الثغرة، لا بد من فهم دور الـ MMU (وحدة إدارة الذاكرة، Memory Management Unit) أولًا: هذه الوحدة هي المسؤولة عن ترجمة العناوين المنطقية التي يستخدمها البرنامج إلى عناوين فعلية في ذاكرة الجهاز. وعندما يشغّل KVM جهازًا افتراضيًا، يحتاج إلى طبقة ترجمة إضافية: عنوان داخل الجهاز الافتراضي يجب أن يُترجم أولًا إلى عنوان داخل ذاكرة ذلك الجهاز الافتراضي، ثم يُترجم مرة أخرى إلى عنوان حقيقي في ذاكرة المضيف. تسمى بنية الجداول التي يبنيها KVM لتتبّع هذه الترجمة المزدوجة Shadow MMU أو Shadow Paging — وهي طبقة “ظل” يديرها المضيف لمحاكاة جداول صفحات الذاكرة الخاصة بالجهاز الافتراضي.
بحسب التحليلات الفنية المنشورة، تكمن المشكلة في دالة داخل ملف arch/x86/kvm/mmu/mmu.c تُدعى kvm_mmu_get_child_sp(). عند إنشاء أو إعادة استخدام صفحة Shadow، كان الكود يتحقق فقط من رقم إطار الذاكرة الخاص بالضيف (guest frame number أو gfn) لتحديد ما إذا كانت صفحة Shadow موجودة مسبقًا يمكن إعادة استخدامها، دون أن يتحقق أيضًا من حقل الدور (role) الذي يحدد نوع تلك الصفحة — هل هي ترجمة مباشرة، أم أنها نسخة ظل عن جدول صفحات آخر تابع للضيف. النتيجة أن صفحتين مختلفتين تمامًا في وظيفتهما، لكنهما تتشاركان رقم إطار الذاكرة نفسه، يمكن أن تُخلطا ببعضهما (type confusion). ومع توقيت دقيق (race condition) بين خيوط تنفيذ متعددة، يمكن استغلال هذا الخلط لجعل المضيف يربط جدول ترجمة بذاكرة لم يكن يفترض أن يصل إليها الضيف إطلاقًا — وهذا ما يفتح الباب أمام تلاعب الجهاز الافتراضي بذاكرة المضيف نفسها بعد تحرير صفحة الذاكرة واستخدامها لاحقًا بشكل خاطئ (Use-After-Free).
الأهم أن هذا الخلل ليس خاصًا بمعالجات Intel أو AMD وحدها، بل يوجد في الكود المشترك بين تقنيتي المحاكاة الافتراضية للأجهزة، أي VMX/EPT من Intel وSVM/NPT من AMD. لهذا وُصفت هذه الحادثة بأنها أول ثغرة هروب من ضيف إلى مضيف (guest-to-host) يمكن تفعيلها على منصتي Intel وAMD معًا حسب ما هو معروف علنًا حتى الآن. الكود المسبب للمشكلة أُدخل عبر الـ commit المعرَّف بـ 2032a93d66fa في أغسطس 2010، أي قبل صدور النواة 2.6.36 نفسها في أكتوبر من العام ذاته.
الخطورة
لا يوجد حتى وقت كتابة هذا المقال درجة CVSS رسمية معتمدة من NVD لهذه الثغرة، والدرجات التي نشرتها جهات أمنية مختلفة متضاربة بشكل لافت: شركة Tenable قيّمتها بـ 7.8 (High) وفق CVSS v3.0، وRed Hat قيّمتها بـ 7.0 (Important)، بينما ذهبت SUSE إلى تقييم أعلى بكثير بلغ 8.8 وفق CVSS v3.1 و9.3 وفق CVSS v4.0. هذا التفاوت بين “عالية” و"شبه حرجة" يعكس اختلاف الجهات في تقييم مدى سهولة الوصول إلى شروط الاستغلال، لكنه لا يغيّر من واقع أن الأثر النهائي — تعطيل المضيف أو احتمال تنفيذ أوامر بصلاحيات كاملة عليه — خطير بأي مقياس.
ما يرفع من أهمية هذه الثغرة تحديدًا هو طبيعة البيئات التي تعتمد على KVM: مزودو الحوسبة السحابية، ومنصات مثل Proxmox، وOpenStack، والشركات التي تُشغّل أجهزة افتراضية متعددة المستأجرين على خوادم مشتركة. في مثل هذه البيئات، يكفي أن يستأجر مهاجم جهازًا افتراضيًا واحدًا فقط ليتمكن — نظريًا — من التأثير على كل الأجهزة الافتراضية الأخرى المستضافة على نفس الخادم الفيزيائي، بما فيها أجهزة عملاء آخرين لا علاقة لهم بالمهاجم إطلاقًا. كما أشارت بعض التحليلات إلى أن عقدة KVM على مستوى النظام، أي الملف /dev/kvm، تكون قابلة للوصول من أي مستخدم غير مميّز افتراضيًا في بعض التوزيعات مثل EL8 وما تلاها، وهو ما يفتح مسارًا إضافيًا لمستخدم محلي غير مميز لتحفيز نفس الخلل مباشرة على المضيف دون المرور عبر جهاز افتراضي أصلًا.
الإصلاح والتخفيف
وصل الإصلاح إلى نواة لينكس الرئيسية عبر الـ commit 81ccda30b4e8، ودُمج في يونيو 2026. المهم هنا أن معالجة الثغرة تتطلب تطبيق إصلاحين مترابطين معًا وليس واحدًا فقط: الإصلاح الأول (CVE-2026-53359) يغلق مسار الهروب نفسه بإضافة التحقق من حقل الدور (role) إلى جانب رقم إطار الذاكرة عند مطابقة صفحات Shadow، والإصلاح الثاني (CVE-2026-46113) عبر الـ commit 0cb2af2ea66a يعالج مشكلة مرتبطة في طريقة معالجة رقم إطار الذاكرة نفسه. تطبيق أحد الإصلاحين دون الآخر لا يغلق الثغرة بشكل كامل.
وصلت هذه الإصلاحات إلى الفروع المستقرة من نواة لينكس بتاريخ 4 يوليو 2026، وشملت الإصدارات: 7.1.3، و6.18.38، و6.12.95، و6.6.144، و6.1.177، و5.15.211، و5.10.260. على مسؤولي الأنظمة والبنية التحتية الذين يديرون خوادم استضافة تعتمد على KVM (وكذلك من يستخدمون منصات مبنية عليه مثل Proxmox) تحديث نواة النظام المضيف إلى أحد هذه الإصدارات أو أحدث في أسرع وقت ممكن، مع التأكد من أن كلا الإصلاحين مطبّقان معًا. وحتى يتم التحديث، توصي عدة جهات أمنية بإجراء مؤقت وهو تعطيل المحاكاة الافتراضية المتداخلة (Nested Virtualization) لأي أجهزة افتراضية غير موثوقة، لأن هذه الميزة أحد الشروط اللازمة لتفعيل مسار الاستغلال. كما يُنصح بمراجعة صلاحيات الوصول إلى /dev/kvm والتأكد من أنه غير متاح لمستخدمين غير مميزين على أنظمة تستضيف بيانات أو أحمال عمل حساسة.
حالة الاستغلال
بحسب ما نُشر علنًا، يتطلب استغلال الثغرة توفر شرطين من جهة الجهاز الافتراضي المهاجِم: صلاحيات root داخل الجهاز الافتراضي نفسه — وهو أمر شائع الحدوث في الأجهزة الافتراضية المستأجرة على السحابة حيث يملك المستأجر تحكمًا كاملًا داخل جهازه — إضافة إلى تفعيل خاصية المحاكاة الافتراضية المتداخلة على المضيف بحيث تكون متاحة للجهاز الافتراضي.
نُشر إثبات مفهوم (Proof of Concept) علني يوضّح مسار إسقاط المضيف: يقوم الجهاز الافتراضي بتحميل وحدة تستولي على حالة المحاكاة الافتراضية الأولية، ثم تُحدث سباقًا (race) يدفع المضيف إلى الانهيار (kernel panic) خلال ثوانٍ إلى دقائق. أما الجزء الأخطر — استغلال كامل يحوّل الثغرة إلى تنفيذ أوامر بصلاحيات root على المضيف نفسه — فقد ذكر الباحث أنه توصّل إليه، لكنه لم يُنشر علنًا حتى وقت كتابة هذا المقال، على الأرجح لإتاحة وقت كافٍ لتطبيق التحديثات قبل أن يصبح الاستغلال الكامل متاحًا لأي مهاجم.
المصدر
المقال الأصلي: 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host on Intel and AMD x86 Systems