CVE-2026-46113 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
KVM: x86: إصلاح استخدام بعد التحرير (use-after-free) في جدولة الظل (shadow paging) بسبب GFN غير متوقع
تحسب MMU الظلية عناوين الصفوف الفيزيائية للضيف (GFNs) لصفحات الظل المباشرة باستخدام sp->gfn بالإضافة إلى فهرس SPTE. ينكسر هذا الافتراض عند استخدام جدولة الظل إذا تم تعديل جداول صفحات الضيف بين إدخالات VM (مشابهًا للالتزام aad885e77496، "KVM: x86/mmu: إسقاط/إزالة وجود SPTE الحالي حتى عند إنشاء MMIO SPTE"، 2026-03-27). تتدفق العملية على النحو التالي:
- يتم تثبيت PDE لتعيين بحجم 2 ميجابايت، ويتم الوصول إلى صفحة في تلك المنطقة. تنشئ KVM كائن kvm_mmu_page يتكون من 512 صفحة حجمها 4 كيلوبايت؛ يُعلّم FNAME(fetch) الكائن kvm_mmu_page بأنه تعيين مباشر (direct-mapped) لأن تعيين الضيف هو صفحة ضخمة (وبالتالي متصلة).
- يتم تغيير تعيين PDE من خارج الضيف.
- يصل الضيف إلى صفحة أخرى في نفس منطقة الـ 2 ميجابايت. تقوم KVM بتثبيت SPTE ورقة جديدة وتسجيل rmap؛ يستخدم SPTE "GFN الصحيح" (أي بناءً على التعيين الجديد، كما تم تغييره في الخطوة السابقة) ولكن ذلك GFN يقع خارج النطاق [sp->gfn, sp->gfn + 511]؛ وبالتالي لا يمكن العثور على تسجيل rmap وإزالته عند إزالة kvm_mmu_page.
- يتم حذف memslot الذي يغطي تعيين الـ 2 ميجابايت الأول، ويتم إزالة kvm_mmu_page الخاص بـ GPA غير الصالح الآن. ومع ذلك، تبحث rmap_remove() فقط في النطاق [sp->gfn, sp->gfn + 511] المحدد في الخطوة 1، وتفشل في العثور على تسجيل rmap الذي تم توثيقه بواسطة الخطوة 3.
- أي عملية تسبب مشيًا عبر rmap للصفحة نفسها التي تمت الوصول إليها بواسطة الخطوة 3 ثم تمرر عبر rmap قديم وتقوم بإلغاء مرجع kvm_mmu_page المحذوف. يشمل ذلك التسجيل القذر (dirty logging) أو إبطال إشعارات MMU (مثل تلك الناتجة عن MADV_DONTNEED).
المشكلة الجذرية هي أن مشي KVM عبر PTEs الظلية يفترض أنه إذا كان SPTE حاضرًا عندما تريد KVM تثبيت SPTE غير ورقة، فإن kvm_mmu_page الموجود يجب أن يكون لـ gfn الصحيح. لأن الطريقة الوحيدة ليكون GFN خاطئًا هي إذا أخطأت KVM وفشلت في إزالة SPTE... وهو ما لا ينبغي أن يحدث، ولكن *في الواقع* يحدث فقط استجابةً لكتابة الضيف.
يعود هذا الخطأ إلى الأزل حرفيًا، حيث حتى النسخة الأولى من KVM تفترض أن GFN يتطابق وتمشي نحو "صفحة الظل الخاطئة". ومع ذلك، كان ذلك مجرد عدم دقة حتى جاء 2032a93d66fa ("KVM: MMU: لا تخصص صفحات gfns لصفحات mmu المباشرة").
إصلاحه عن طريق التحقق من عدم تطابق GFN المستهدف وإزالة SPTE الحالي. بهذه الطريقة تختفي الـ SP وعمليات rmap القديمة، وتقوم KVM بتثبيت rmap في الموقع الصحيح، ويكون الجميع سعداء.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.