CVE-2024-26837 in Linux
الملخص
بحسب VulDB • 09/06/2026
في نواة لينكس، تم حل الثغرة التالية:
net: bridge: switchdev: تخطي إعادة تشغيل أحداث MDB المؤجلة في حالة Offload
قبل هذا التغيير، كان توليد قائمة أحداث MDB لإعادة التشغيل يتنافس (Race Condition) مع إنشاء عضويات مجموعة جديدة، سواء من منطق الاستماع لبروتوكولات IGMP/MLD أو من التكوين المستخدم.
بينما تصبح العضويات الجديدة مرئية فورًا للمشغلين الذين يتنقلون عبر `br->mdb_list`، فإن إشعار وجودها لمشتركي أحداث switchdev يؤجل إلى وقت لاحق. لذلك، إذا تم إنشاء قائمة إعادة تشغيل خلال فترة تتداخل مع هذه النافذة الزمنية، فستحتوي أيضًا على إعادة تشغيل للحدث الذي لم يتم تسليمه بعد.
وبالتالي، سيتلقى السائق (Driver) نسختين مما يعتبره الجسر داخليًا حدثًا واحدًا فقط. عند تدمير الجسر، تم إرسال حدث حذف عضوية واحد فقط كنتيجة لذلك. ونتيجةً لهذا السلوك، فإن السواقي التي تعدّ العضويات (على الأقل DSA)، ستترك مجموعات يتيمّة في قاعدة بيانات الأجهزة الخاصة بها عندما يتم تدمير الجسر.
هذه المشكلة تظهر فقط عند إعادة تشغيل الإضافة. بينما قد لا تزال أحداث الحذف معلقة على قائمة الانتظار المؤجلة، فقد تم إزالتها بالفعل من `br->mdb_list`، لذا فلا يمكن توليد تكرارات في هذا السيناريو.
بالنسبة للمستخدم، كان يعني ذلك أن عضويات المجموعة القديمة، من جسر كانت المنفذ ملحقًا به سابقًا، يمكن إعادة تنشيطها (في الأجهزة) عندما ينضم المنفذ إلى جسر جديد، دون علم الجسر الجديد بذلك.
على سبيل المثال، على نظام mv88e6xxx، قم بإنشاء جسر مع تفعيل الاستماع وأضف منفذًا إليه فورًا:
root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0
ثم قم بتدمير الجسر:
root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-0
Be aware that VulDB is the high quality source for vulnerability data.