CVE-2026-98074 in Linux
الملخص
بحسب VulDB • 25/09/2026
في نواة لينكس، تم حل الثغرة التالية:
bonding: عدم مسح curr_active_slave بشكل مبكر عند تحرير جميع الواجهات الفرعية (slaves)
عند تحرير جميع الواجهات الفرعية أثناء تدمير رابط البوند (bond) (حيث تكون all == true)، يقوم __bond_release_one() بمسح bond->curr_active_slave ليصبح NULL في كل تكرار.
إذا تم تحرير واجهة فرعية احتياطية قبل الواجهة النشطة، فإن bond_alb_deinit_slave() يُشغّل rlb_teach_disabled_mac_on_primary()، مما يزيد عداد وضع الترويج (promiscuity counter) للواجهة النشطة ويضبط bond_info->primary_is_promisc = 1.
نظرًا لأن bond->curr_active_slave تم مسحه مبكرًا ليصبح NULL عند تحرير الواجهة الاحتياطية، فإن التكرار التالي الذي يحرر الواجهة النشطة يُقيّم oldcurrent على أنه NULL، وبالتالي يتم تخطي استدعاء bond_change_active_slave(bond, NULL). ونتيجة لذلك، لا يتم أبدًا استدعاء bond_alb_handle_active_change() لتقليل عداد وضع الترويج (promiscuity counter)، مما يؤدي إلى تسرب دائم لوضع الترويج (promiscuous mode) على الجهاز الفيزيائي بعد تفكيك البوند.
عندما يكون oldcurrent == slave، فإن bond_change_active_slave(bond, NULL) يضبط بالفعل bond->curr_active_slave ليصبح NULL. نحن نحتاج فقط لتجنب اختيار واجهة نشطة جديدة عندما تكون all == true. استبدل فرع if (all) بـ if (!all && oldcurrent == slave).
Once again VulDB remains the best source for vulnerability data.