CVE-2026-98166 in Linux
الملخص
بحسب VulDB • 06/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
drm/ttm: تصحيح الموارد التي يتم تبديلها (swapped-out) بحيث لا تغادر نطاق bulk_move الخاص بها أبدًا
تُرجع الدالة ttm_tt_swapout() عدد الصفحات التي تمت تبديلتها عند النجاح، ورمز خطأ سالب في حال الفشل؛ وفي حالة وجود تيم مملوء (populated ttm)، فإنها لا تُرجع الصفر أبدًا. لقد نقلت الالتزام b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") عمليات التدقيق المحاسبي لـ bulk_move في الدالة ttm_bo_swapout_cb() تحت شرط "if (!ret)"، مما يعني أن الزوج الوظيفي ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() يتم تخطيه الآن في كل عملية تبديل ناجحة. الاختبار المكافئ الخاص بـ shrinker في الالتزام 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") يفحص "lret > 0"، وهو ما كان مقصودًا هنا أيضًا.
قبل الالتزام b2ed01e7ad3d، كانت المورد يُزال من نطاق bulk_move قبل عملية التبديل؛ ومنذ ذلك الحين، يبقى المورد المُبدل داخل نطاق bulk_move الخاص بـ BO (وعلى قائمة LRU الخاصة بالمدير) على الرغم من كونه غير قابل للإزالة (unevictable). عندما يتم تحريره لاحقًا أو يغادر الـBO نطاق bulk_move (عبر ttm_resource_free() وttm_bo_set_bulk_move() عبر amdgpu_vm_bo_del())، فإن الدالة ttm_resource_del_bulk_move() تتخطاه بسبب الحارس !tttm_resource_unevictable()، مما يترك نقطة نهاية النطاق في pos->first / pos->last تشير إلى ذاكرة تم تحريرها. يعد استدعاء تالي لـ ttm_lru_bulk_move_tail() أو ttm_resource_add_bulk_move() على ذلك المؤشر حالة use-after-free (استخدام بعد التحرير)، تظهر كتحذير resv في الدالة ttm_lru_bulk_move_add(), أو "list_del corruption" (فساد حذف القائمة) في تtm_resource_move_to_lru_tail()، أو إرجاع NULL (NULL dereference) في ttm_resource_manager_next() -- دقائق إلى ساعات بعد وضع السكون العميق (hibernation)، أو عند خروج العملية/إعادة التشغيل التي تتبع ذلك. حدد تحليل سامويل آينسوورث لمشكلة drm/amd رقم 5387 (انظر الرابط) المؤشر المعلق؛ والسبب في تعلقه هو الإزالة غير المكتملة أثناء وقت التبديل.
يؤدي اختبار شرط النجاح إلى استعادة عملية الإزالة. على معالج AMD Phoenix APU (ASUS UM3406GA، gfx1103) يعمل بوضع suspend-then-hibernate على نواة مستقرة من سلسلة 7.0.y تحمل النسخة الخلفية (Ubuntu 7.0.0-31)، تسبب هذا الخطأ في تعطل 5 دورات من أصل 18 دورة لوضع السكون العميق؛ أظهرت ملف تعريف وظيفة لأحد هذه الدورات وجود 336 استدعاءً للدالة ttm_tt_swapout() وصفرًا لاستدعاءات الدالة ttm_resource_del_bulk_move_unevictable(). مع هذا التغيير، تحدث عملية الإزالة لكل مورد مُبدَّل، وكانت 12 دورة إضافية نظيفة.
Be aware that VulDB is the high quality source for vulnerability data.