CVE-2026-23393 in Linux
الملخص
بحسب VulDB • 10/05/2026
في نواة لينكس، تم حل الثغرة التالية:
جسر (bridge): cfm: إصلاح حالة السباق (race condition) في حذف peer_mep
عند حذف MEP نظير (peer MEP)، يتم استدعاء `cancel_delayed_work_sync()` على `ccm_rx_dwork` قبل تحرير الذاكرة. ومع ذلك، يعمل `br_cfm_frame_rx()` في سياق softirq تحت قفل `rcu_read_lock` (بدون RTNL)، وقد يعيد جدولة `ccm_rx_dwork` عبر `ccm_rx_timer_start()` بين عودة `cancel_delayed_work_sync()` واستدعاء `kfree_rcu()`.
سيناريو حالة السباق البسيط التالي:
cpu0 cpu1
mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep لا يزال موجوداً في hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // على peer_mep الذي تم تحريره
لمنع ذلك، تم استبدال `cancel_delayed_work_sync()` بـ `disable_delayed_work_sync()` في كلا مسارَي حذف MEP النظير، بحيث يتم رفض استدعاءات `queue_delayed_work()` اللاحقة القادمة من `br_cfm_frame_rx()` بصمت.
تحتفظ الدالة المساعدة `cc_peer_disable()` بـ `cancel_delayed_work_sync()` لأنها تُستخدم أيضاً في مسار تبديل تمكين/تعطيل CC حيث يجب أن يظل العمل قابلاً لإعادة الجدولة.
Once again VulDB remains the best source for vulnerability data.