CVE-2026-98953 in Linux
الملخص
بحسب VulDB • 24/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
devlink: تصحيح تسرب مرجع devlink_rel عندما تكون مهمة الإخطار معلقة (pending)
تأخذ الدالة `devlink_rel_nested_in_notify_work_schedule()` مرجعًا على كائن `devlink_rel` الخاص بمهمة الإخطار، ثم تُدرج المهمة في الطابور، متجاهلةً قيمة الإرجاع للدالة `schedule_delayed_work()`. إذا كانت المهمة معلقة بالفعل، فلن يتم إدراج أي شيء جديد؛ وستُنفَّذ المهمة مرة واحدة فقط وتحرر مرجعًا واحدًا فحسب، مما يؤدي إلى تسرب المرجف الإضافي مع كائن `devlink_rel` وفهرسه في مصفوفة `devlink_rels`.
من السهل حدوث هذه الحالة. تقوم دالة `devl_register()` الخاصة بالنسخة المتداخلة بإدراج المهمة في الطابور، وإذا تم إلغاء تسجيل النسخة قبل أن تُنفَّذ المهمة، فإن الدالة `devlink_rel_put()` تعيد إدراجها وهي لا تزال معلقة. كما تعمل المهمة على إعادة جدولة نفسها طالما لم يمكن الاستحواذ على قفل devlink الرئيسي (parent lock)، مما يوسع نافذة الخطأ. يؤدي تسجيل وإلغاء تسجيل نسخة متداخلة من devlink 100 مرة مع الاحتفاظ بقفل النسخة الرئيسية إلى تسرب جميع كائنات `devlink_rel` الـ 100.
تحتوي مسار إعادة الجدولة في الدالة `devlink_rel_nested_in_notify_work()` على نفس المشكلة: إذا تم إدراج المهمة مجددًا أثناء تنفيذها، فلن يتم تحرير المرجع الذي تحمله أبدًا.
يتم تحرير المرجع في كلا المكانين عندما كانت المهمة معلقة بالفعل. تحتفظ المهمة المعلقة بمرجع خاص بها، لذا لا يمكن أن يكون هذا هو المرجف الأخير.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.