CVE-2026-99166 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net: rds: تصحيح الإحالة غير المهيأة (uninitialized dereference) للمتغير trans في معالج أحداث الاتصال (CM event handler).
تقوم الدالة `rds_rdma_cm_event_handler_cmn()` بتعيين المتغير `trans` فقط عندما يكون جهاز RDMA عبارة عن InfiniBand CA (`RDMA_NODE_IB_CA`). وعلى أي نوع آخر من الأجهزة، مثل بطاقة RNIC iWARP كـ siw، يبقى `trans` غير مهيّأ (uninitialized)، لكن مفتاح الأحداث يقوم بالإحالة إليه: بشكل غير مشروط في حالة `RDMA_CM_EVENT_CONNECT_REQUEST` عبر `trans->cm_handle_connect()`، و(مع سياق اتصال) في حالتي `ROUTE_RESOLVED` و `ESTABLISHED`.
وبالتالي، فإن مستمع RDS على جهاز iWARP يؤدي إلى انهيار النواة (kernel crash) بمجرد وصول طلب الاتصال: مع تفعيل خيار التكوين `CONFIG_INIT_STACK_ALL_ZERO`، تصبح القراءة العشوائية إحالة NULL عند الإزاحة 0xa0 (`&trans->cm_handle_connect`) في طابور العمل iw_cm_wq.
تخفي مترجم GCC هذه الثغرة في البناءات الافتراضية من خلال دمج التحميل غير المهيّأ مع `&rds_ib_transport`؛ أما النواة التي تم بناؤها باستخدام Clang فتسلك المسار الحقيقي للقيمة غير المهيأة وتسبب خطأ (oops).
يمكن أن يقع الجانب الفاعل على جهاز غير IB أيضًا: المعرف الذي تنشئه الدالة `rds_ib_conn_path_connect()` ليس مقيدًا بنوع عقدة معين، لذا فإن `rdma_resolve_addr()` تربطه بأي جهاز يخدم العنوان المحلي، وبذلك تتأهل بطاقة RNIC iWARP الموجودة على نفس واجهة الشبكة (netdev). الانهيار هنا مختلف: حل المسار على معرف iWARP لا يقوم بملء `cm_id->route.path_rec` أبدًا، وحالة `ROUTE_RESOLVED` تكتب في `path_rec[0].sl` قبل استدعاء النقل.
تم التخلي عن نقل iWARP منذ فترة طويلة و IB هو النقل الوحيد المتبقي، لذا تم جعل ذلك صريحًا: يتم تهيئة `trans` إلى `&rds_ib_transport` عند الإعلان عنه، وإسقاط التعيين الشرطي، ورفض طلب الاتصال الذي يصل على جهاز غير IB، والتخلص من اتصال حُل عنوانه إلى جهاز غير IB بدلاً من حل مسار عليه. الرفض مقصور عمدًا على حالة `RDMA_CM_EVENT_CONNECT_REQUEST`: لأن الإرجاع بقيمة لا تساوي صفرًا من المعالج يجعل rdma_cm يدمر المعرف (id) الذي تم تسليم الحدث عليه، وهو أمر صحيح للمعرف الجديد المنشأ لطلب الاتصال، لكنه سيؤدي إلى تحرير معرف اتصال ما زال RDS يمتلكه لأي حدث آخر. على الجانب الفاعل يبقى المعرف في `ic->i_cm_id` ويتم تدمير الاتصال عن طريق إيقاف التشغيل، لذا فإن هذه الحالة ترجع 0.
[achender: رفض فقط عند حدوث RDMA_CM_EVENT_CONNECT_REQUEST بدلاً من الخروج لكل حدث على جهاز غير IB، بحيث لا يقوم rdma_cm بتدمير معرفات الاتصالات التي يتتبعها RDS بعد؛ التخلص من اتصال حُل عنوانه إلى جهاز غير IB قبل حل مسار عليه؛ تعديل سجل التغيير (changelog)]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.