CVE-2026-80893 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
mm/hugetlb: تصحيح تلف مدخلات التبادل (swap entry) عند إزالة علامة uffd-wp أثناء استدعاء fork()
تقوم دالة `copy_hugetlb_page_range()` بإزالة بت علامة uffd-wb من مدخلات الهجرة (migration) والتسمم العتادي (hwpoison) باستخدام الدالة `huge_pte_clear_uffd_wp()`، والتي تعمل على موضع بت PTE الحالي (present-PTE). تحتفظ مدخلات التبادل بحالة uffd-wp في مكان آخر — حيث تقرأ وتضبط هذه العلامة عبر دالتي `pte_swp_uffd_wp()` و`pte_swp_mkuffd_wp()` — بينما يقع موضع بت PTE الحالي ضمن حمولة التبادل (swap payload). على معمارية x86-64، يسقط هذا الموضع في إزاحة التبادل المعكوسة (inverted swap offset)، حيث يكون لرقم صفحة الهووتلب (hugetlb PFN) المحاذاة طبيعياً البت المتأثر مضبوطاً دائماً، مما يؤدي إلى تقدم الـ PFN المشفر بمقداد صفحتين.
لا حاجة لإشراك أي مستخدمfaultfd: فعملية الإزالة محمية فقط بعدم تسجيل VMA للطفل كـ uffd-wp، لذا فإن استدعاء fork() عادي مع وجود مدخل هجرة hugetlb قيد التنفيذ (أو صفحة hugetlb مسمومة) يؤدي إلى تلف المدخل المنسوخ إلى الطفل. إظهار عملية الإضافة وإجراء fork() بعد استخدام MADV_HWPOISON على صفحة anon hugetlb بحجم 2MB يُظهر:
offset before=120e00 offset after =120e02
النتائج المترتبة هي في الغالب كامنة (latent): تطابق عمليات rmap.walk مدخلات الهجرة بنطاق folio، وإعادة بناء `remove_migration_pte()` لـ PTE من الـ folio، مما يعني أن انحراف PFN داخل نطاق الـ folio يُشفى بمجرد اكتمال عملية الهجرة. لكن أي مسار يعيد تشفير الإزاحة التالفة — على سبيل المثال دالة `hugetlb_change_protection()` التي تعيد كتابة مدخل هجرة قابل للكتابة عبر `make_readable_migration_entry(swp_offset(entry))` — تنقل هذا التلف.
تحمل مدخلات الهجرة بشكل شرعي علامة uffd-wp، لذا يجب إزالتها باستخدام `pte_swp_clear_uffd_wp()`, متوافقة مع `copy_nonpresent_pte()` و`move_huge_pte()`.
من ناحية أخرى، لا يحمل مدخل التسمم العتادي (hwpoison entry) بت علامة uffd-wp أبداً: فهو يُثبت حديثاً بواسطة دالة `make_hwpoison_entry()` (حيث لا تحافظ `try_to_unmap_one()` على علامة uffd-wb في مسار hwpoison)، وتترك دالة `hugetlb_change_protection()` مدخلات hwpoison دون مساس. لم يكن هناك ما يجب إزالته هنا، بل كان التلف فقط، لذا تم حذف عملية الإزالة تماماً.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.