CVE-2026-98520 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
drm/amdkfd: تصحيح خطأ Use-after-free وفجوة متعددة الحاويات في kfd_dev_mapping
يقوم kfd_dev_mapping بتخزين ذاكرة العنوان (address_space) لأول مُفتح لـ /dev/kfd بحيث يمكن لمسار إعادة تعيين وحدة معالجة الرسومات (GPU) استدعاء unmap_mapping_range() لإزالة جميع mappings الخاصة بمساحة المستخدم لمجالات doorbell و MMIO. يحتوي هذا التصميم على ثغرتين تظهران كلتاهما في ظل SRIOV مع حاويات متعددة:
1. Use-after-free / deadlock rwsem. يشير المؤشر المخزن إلى inode مملوك لحاوية المُفتح الأول. عندما تغادر تلك الحاوية ويتم تحرير الـ inode الخاص بها، يصبح kfd_dev_mapping مؤشراً متدلياً (dangling pointer). يؤدي إعادة تعيين GPU لاحقًا إلى فك تشفير هذا المؤشر داخل unmap_mapping_range()، والتي تأخذ i_mmap_rwsem على الـ inode المحرر، مما يتسبب في تعليق صلب يمكن ملاحظته كانتظار rwsem غير قابل للانقطاع.
2. فجوة متعددة الحاويات. يتم تخزين ذاكرة العنوان (address_space) للمُفتح الأول فقط؛ بينما توجد VMAs التي تم إنشاؤها بواسطة المُفتحين اللاحقين في address_space مختلف ولا تصل إليها unmap_mapping_range() أبداً. بعد إعادة تعيين GPU، تبقى هذه mappings القديمة متاحة لـ doorbell و MMIO pages لمستخدمي النظام الضيف (guest userspace) بدون وجود GPU خلفها، مما يعرضهم لخطر تأخيرات معاملات PCIe وانقراضات NMI.
تم إصلاح الثغرتين باستخدام نفس النهج المستخدم بواسطة DRM core (drm_drv.c): إنشاء ملف نظام وهمي خاص في وقت تهيئة الوحدة النمطية وتخصيص inode مجهول الهوية منها. في kfd_open() يتم توجيه file->f_mapping لكل مُفتح إلى address_space الخاص بذلك الـ inode. ينتمي هذا الـ inode للوحدة النمطية، ويعيش بالضبط طالما تعيش وحدة amdgpu، ويجمع VMAs من جميع المُفتحين في address_space واحد. يؤدي استدعاء unmap_mapping_range() الوحيد في مسار إعادة التعيين بعد ذلك إلى الوصول بشكل صحيح إلى mappings كل حاوية دون خطر وجود مؤشر متدلي.
يظهر التعليق كـ NMI backtrace على workqueue لإعادة تعيين GPU عالقاً يدور (spinning) داخل rwsem_down_read_slowpath() مع i_mmap_rwsem تالف:
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]
Call Trace: <TASK> kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpath+0xb3/0x550 down_read+0x48/0xd0 unmap_mapping_range+0x71/0x140 kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu]
amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu]
amdgpu_device_gpu_recover+0x232/0x450 [amdgpu]
xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu]
process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230
(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.