CVE-2026-72115 in Linux
الملخص
بحسب VulDB • 16/08/2026
في نواة لينكس، تم حل الثغرة التالية:
can: bcm: تتبع واجهة مصدر واحدة فقط لعمليات ANYDEV الخاصة بوقت الانتظار (timeout) أو الحد من السرعة (throttle)
لا توجد دلالات محددة لعملية استقبال RX على واجهة ANYDEV (حيث ifindex == 0) عند وجود مؤقت لاستقبال البيانات (RX timeout) و/أو مؤقت للحد من السرعة نشط، في حال وصول إطارات متطابقة من عدة واجهات: يمكن أن تعمل دالة bcm_rx_handler() بشكل متزامن لنفس العملية على معالجات مختلفة، مما يؤدي إلى سباق بين استدعاء hrtimer_cancel()/bcm_rx_starttimer() ودالة bcm_rx_timeout_handler()، مسبباً إشعارات RX_TIMEOUT زائفة وتلفاً في حقول last_frames. يسمح نفس التوازي لإطارات التعدد (multiplex) المقيدة بالسرعة القادمة من واجهات مختلفة بتجاوز الحقول rx_ifindex/rx_stamp المشتركة بين العمليات.
تمت إضافة op->if_detected لتتبع الواجهة الأولى التي تسلّم إطاراً متطابقاً بينما يكون مؤقت وقت الانتظار/الحد من السرعة مضبوطاً، ورفض الإطارات القادمة من أي واجهة أخرى لهذه العملية. يتم تحديد الادعاء (claim) في bcm_rx_handler() قبل أن يلمس hrtimer_cancel() op->timer، لذا فإن الإطار المرفوض لا يمكنه أبداً إزعاج مراقب الواجهة المدعية (watchdog). تم استبعاد عمليات وضع RTR عبر RX_RTR_FRAME، بشكل مستقل عن kt_ival1/kt_ival2، لأن تلك القيم قد تحتفظ بقيمة قديمة لفترة وجيزة من تكوين سابق غير متعلق بوضع RTR.
يتم تحرير الادعاء في bcm_notify() عند حدث NETDEV_UNREGISTER وفي bcm_rx_setup() عندما يعيد SETTIMER ضبط قيم المؤقتات.
لا يمكن حدوث (إعادة) ادعاء إلا على أجهزة CAN التي تكون حالتها reg_state ضمن dev->reg_state من نوع NETREG_REGISTERED، لتغطية عملية التحرير في bcm_notify() حيث تصبح الحالة reg_state هي NETREG_UNREGISTERING حتى يتم استدعاء synchronize_net().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.