CVE-2026-90081 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net/rds: استخدام wq_has_sleeper() في دالة rds_cong_map_updated()
تعمل الدالة `rds_cong_map_updated()` بعد إعادة كتابة خريطة الازدحام الخاصة بنظير (peer) (من خلال `rds_tcp_cong_recv()` و`rds_ib_cong_recv()`، أو عملية المسح الشامل في مسارات الإكمال للإرسال عبر الحلقة المحلية loopback وIB). تقوم هذه الدالة بزيادة قيمة العداد `rds_cong_generation` ثم تتحقق من حالة طابور الانتظار باستخدام `waitqueue_active()` على `map->m_waitq` وعلى `rds_poll_waitq` لتحديد ما إذا كان هناك أي مستخدم يحتاج إلى التنبيه (waking). لا تحمل عملية الزيادة الذرية (`atomic_inc()`) أي ترتيب زمني، و`waitqueue_active()` هي مجرد قراءة عادية؛ وبالتالي، فلا يوجد أي ضمان لترتيب عمليات تخزين الخريطة والعداد قبل قراءات طابور الانتظار. يقوم المستثمرون/المنتظرون (waiters) بعكس الصورة: تضيف `rds_cong_wait()` نفسها إلى `m_waitq` ثم تختبر بت المنفذ (port bit)، وتسجل `rds_poll()` في `rds_poll_waitq` ثم تقرأ قيمة العداد. هذا يمثل نمط تخزين المخزن المؤقت للعمليات (store-buffering pattern) الموصوف أعلاه لـ `waitqueue_active()` في ملف include/linux/wait.h - حيث يمكن للمحدث أن يلاحظ طابور انتظار فارغ بينما لا يزال المنتظر يرى المنفذ كمشبع بالازدحام، ولا يتم إصدار أي تنبيه.
تعد `rds_cong_wait()` عملية نوم قابلة للانقطاع (interruptible sleep) بدون مهلة زمنية محددة، لذا يبقى المرسل المحظور على منفذ مشبع بالازدحام محجوباً حتى وصول تحديث الازدحام التالي من ذلك النظير أو تسليم إشارة نظام التشغيل. ويحدث نفس الشيء لمنتظر `poll()` الذي يفوت إشعار تحديث الخريطة بنفس الطريقة.
استخدم دالة `wq_has_sleeper()`، وهي نسخة من `waitqueue_active()` تسبقها حاجز كامل (full barrier) مطلوب، كما تفعل بالفعل `rds_tcp_state_change()` للنمط نفسه.
Be aware that VulDB is the high quality source for vulnerability data.