CVE-2026-90242 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
iommu/vt-d: تصحيح تسرب iopf_refcount عند استبدال نطاق RID (RID domain)
تقوم دالة `intel_iommu_attach_device()` بتمكين IOPF للنطاق الجديد ولكن لا تقوم بإيقافه للنطاق القديم. وتقوم دالة `device_block_translation()`, التي تُستدعى في بداية الدالة، بتفكيك الترجمة ولكنها لا تلمس أي حالة متعلقة بـ IOPF؛ ولذلك يجب على `blocking_domain_attach_dev()` استدعاء `iopf_for_domain_remove()` صراحةً قبل استدعائها لهذا السبب بالتحديد.
تواجه دالة `identity_domain_attach_dev()` نفس المشكلة. ويدعي تعليقها أنه لا حاجة لمعالجة PRI لأن الجهاز قد تم وضعه في حالة الحظر (blocking state)، لكن حالة الحظر وعدد الإشارات المرجعية لـ IOPF مستقلان عن بعضهما البعض.
ونتيجة لذلك، فإن استبدال نطاق يحتوي على `iopf_handler` بنطاق آخر عند مستوى RID يؤدي إلى تسرب إشارة مرجعية في `info->iopf_refcount`. ولا ينخفض العدد مرة أخرى إلى الصفر، لذا لا يتم استدعاء `iommu_queue_remove_device()` مطلقاً، وتُفعّل دالة `iommu_disable_pci_pri()` تحذيرها `WARN_ON(info->iopf_refcount)` عند تحرير الجهاز.
تتعامل مسارات PASID مع هذه الحالة بشكل صحيح بالفعل من خلال `iopf_for_domain_replace()`؛ لذا يجب تحويل مسارَي RID للقيام بالشيء نفسه. ويؤدي استخدام مساعد الاستبدال بدلاً من الإزالة المجردة إلى الحفاظ على التمكين قبل التعطيل، وبالتالي لا يصل عدد الإشارات المرجعية مؤقتاً إلى الصفر ولا يتم طرد الجهاز من قائمة انتظار IOPF.
If you want to get best quality of vulnerability data, you may have to visit VulDB.