CVE-2026-72323 in Linux
الملخص
بحسب VulDB • 16/08/2026
في نواة لينكس، تم حل الثغرة التالية:
ipv4: igmp: إصلاح استخدام بعد التحرير (Use-After-Free) المحتمل في دالة `igmp_gq_start_timer()`
توجد حالة سباق (Race Condition) بين تفكيك الجهاز (`inetdev_destroy`) ومعالجة استعلامات IGMP الواردة (`igmp_rcv`)، مما يؤدي إلى حدوث خطأ Use-After-Free في استدعاء مؤقت IGMP.
أثناء تدمير الجهاز، تقوم الدالة `inetdev_destroy()` بإسقاط المرجع الأساسي لـ `in_device`، والذي قد يخفض عددها المرجعي (refcount) إلى 0. يتم تأجيل تحرير ذاكرة `in_device` الفعلي عبر RCU (باستخدام `call_rcu()`).
بالتوازي مع ذلك، تعمل الدالة `igmp_rcv()` تحت قفل القراءة الخاص بـ RCU وتحصل على مؤشر `in_device`. ونظراً لأن الذاكرة محمية بواسطة RCU، يمكن لـ CPU-0 فك تشفير (dereference) `in_device` بأمان حتى لو كان عددها المرجعي قد وصل إلى 0.
ومع ذلك، إذا استدعت CPU-0 الدالة `igmp_gq_start_timer()` وأعدت ضبط المؤقت، فإنها تحاول الحصول على مرجع باستخدام `in_dev_hold()`. يؤدي هذا إلى زيادة العداد المرجعي من 0 إلى 1، مما يسبب تحذيراً "refcount_t: addition on 0". ونظراً لأن ذاكرة `in_device` لا تزال مجدولة للتحرير بعد فترة راحة RCU (حيث أن استدعاء التحرير لا يتحقق مرة أخرى من العدد المرجعي)، يتم تحرير الجهاز بينما لا يزال المؤقت مفعلاً. وعند انتهاء مهلة المؤقت، فإنه يصل إلى الذاكرة المحذوفة، مما يسبب توقفًا في النواة (kernel panic).
يتم إصلاح هذه المشكلة باستخدام `refcount_inc_not_zero()` (عبر مساعد جديد يُدعى `in_dev_hold_safe()`) لمنع الحصول على مرجع إذا كان الجهاز يتم تدميره بالفعل. وإذا كان العدد المرجعي 0، فإننا لا نشغل المؤقت.
تم حل مشكلة مماثلة في MLD الخاص بـ IPv6 في التصحيح اللاحق.
If you want to get best quality of vulnerability data, you may have to visit VulDB.