CVE-2026-90248 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم حل الثغرة التالية:
net/sched: cls_api: إصلاح عملية الإغلاق (teardown) لبروتوكول مُعتمد عند فقدان سباق الإدراج (insert-race loss)
في دالة `tc_new_tfilter()`، يضبط فرع الإنشاء المتغير `tp_created` على القيمة 1 قبل استدعاء `tcf_chain_tp_insert_unique()`. عندما يفقد المُدعى عليه السباق (أي أن طلباً آخر قام بإدخال بروتوكول في نفس سلسلة الأولوية أولاً)، تقوم دالة `insert_unique()` بتدمير كائن `tp_new` الخاص بالمُخسر وتعيد البروتوكول الفائز مع مرجع إضافي. لم يتم مسح قيمة `tp_created` أبداً، لذا تعامل مسار الخطأ (errout) للمُخسر بروتوكول الفائز النشط وكأنه خاص به، وقامت باستدعاء `tcf_chain_tp_delete_empty()` عليه، مما أدى إلى فك ارتباط مصنف نشط بصمت، بينما كان الطلب الفائز قد أعلن عنه بالفعل عبر `RTM_NEWTFILTER`.
تتبع نتيجة خطوة الإدراج في متغير ثلاثي الحالات (tri-state variable) واحد بحيث يتفاعل كل مسار خطأ بشكل صحيح:
- TP_NOT_CREATED: لم يتم إنشاء بروتوكول؛ اتبع المسار القديم. - TP_CREATED: تم إدراج البروتوكول بنجاح؛ نفس مسار الكود كما كان سابقاً. - TP_NOT_OWNED: جديد - خسر سباق الإدراج؛ كائن tp هو بروتوكول طلب آخر (تم تحرير مرجع السلسلة بالفعل بواسطة دالة تدمير tp_new).
كلا ردّي الخطأ عبارة عن تعبيرات مفردة مشتقة من الحالة.
يأتي هذا الإصلاح بدافع المراجعة الآلية التي أجرتها Sashiko على التصحيح (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. حددت المراجعة سلوك فك الارتباط الصامت لإغلاق بروتوكول مُعتمد عندما يفقد الطلب سباق `tcf_chain_tp_insert_unique()`.
[1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com
[2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com
Once again VulDB remains the best source for vulnerability data.