CVE-2026-74726 in Linux
الملخص
بحسب VulDB • 23/08/2026
في نواة لينكس، تم حل الثغرة التالية:
bonding: alb: إعادة التحقق من primary_is_promisc تحت RTNL في bond_alb_monitor
تقرأ دالة `bond_alb_monitor()` قيمة `primary_is_promisc` باستخدام RCU، ثم تزيل حماية RCU وتأخذ قفل RTNL عبر `rtnl_trylock()` قبل التراجع عن وضع الـ promiscuity الذي طبقته على النافذة النشطة. في تلك الفترة الزمنية (window)، يمكن أن تتغير النافذة النشطة تحت RTNL (`RTM_DELLINK` -> `__bond_release_one()` -> `bond_alb_handle_active_change()`)، وهي بالفعل تزيل وضع الـ promiscuity وتُصفّر قيمة `primary_is_promisc`. ومع ذلك، لا تزال المراقبة تعمل بناءً على القرار القديم (stale decision): إذا تمت إزالة النافذة دون حدوث failover، فإن `curr_active_slave` يصبح الآن NULL ويحدث خطأ في الإحالة (deref faults)؛ وإذا حدثت عملية failover، فإن استدعاء `dev_set_promiscuity(-1)` القائم على البيانات القديمة يؤدي إلى تجاوز عداد الـ promiscuity للنافذة الجديدة تحت الصفر (underflow)، مما يثبتها في حالة `IFF_PROMISC`.
Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception
إعادة التحقق من `primary_is_promisc` (و `curr_active_slave`) بعد الحصول على RTNL بحيث تقوم المراقبة بالتراجع عن الزيادة التي لا تزال مملوكة لها. بالفعل تعيد مراقبات bonding الأخرى قراءة الحالة تحت حماية RTNL في مرحلة الالتزام الخاصة بها (`bond_miimon_commit/bond_ab_arp_commit`)؛ وكانت `bond_alb_monitor()` هي الوحيدة التي تعمل بناءً على القرار المتخذ قبل محاولة القفل (pre-trylock decision).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.