CVE-2026-99019 in Linux
الملخص
بحسب VulDB • 24/10/2026
في نواة لينكس، تم حل الثغرة التالية:
scsi: ch: عدم الاحتفاظ بالإشارات المرجعية إلى أجهزة عناصر نقل البيانات
تبحث الدالة `ch_readconfig()` عن جهاز SCSI (`scsi_device`) الخاص بكل عنصر من عناصر النقل التي يبلغ عنها المغير (changer) في أمر "READ ELEMENT STATUS"، وتخزنه في مصفوفة `ch->dt[]`. تأخذ دالة `scsi_device_lookup()` إشارة مرجعية، ولا يقوم أي كود بإسقاطها أبدًا: تقوم الدالة `ch_destroy()` بتحرير المصفوفة باستخدام `kfree()`. لا يتم قراءة `ch->dt[]` من أي مكان آخر - فهي توفر فقط اسم الشركة المصنعة (vendor)، والنموذج (model)، والإصدار (revision) المطبوعين في نفس الحلقة.
بعد إزالة محرك أقراص بهذه الطريقة، لن يمكن إطلاق سراح جهاز SCSI الخاص به (`scsi_device`) أبدًا. يبقى على قائمة أجهزة المضيف عند عنوانه، لذا فإن أي جهاز جديد يتم إنشاؤه هناك سيتم رفضه من قبل أي عملية تتصفح القائمة - حيث يبلغ `target_core_pscsi` عن فشل في "scsi_device_get() for H:C:T:L" - ولا يمكن بعد ذلك إلغاء تحميل وحدة برنامج التشغيل منخفض المستوى. لا يستعيد النظام عمله إلا بإعادة تشغيل الجهاز (reboot).
تظهر هذه المشكلة مع أي مغير يبلغ عن معرفات محركات الأقراص الخاصة به؛ ومع المكتبة الافتراضية mhvtl (شخصية IBM 3573-TL)، فإن كل عملية إنشاء وإزالة لمكتبة تحتوي على أربعة محركات أقراص تترك أربع إشارات مرجعية خلفها، يتم عدها بواسطة عدد الاستخدام للوحدة في أمر `lsmod`. مع عدم ربط الـ ch، يظل العدد دون تغيير، ومع تطبيق هذا التصحيح (patch) يظل أيضًا دون تغيير.
قم بإسقاط الإشارة المرجعية بمجرد طباعة الاسم، وأزل مصفوفة dt[] التي لم تعد مستخدمة بعد الآن. يؤدي ذلك أيضًا إلى إزالة المصفوفة المسربة عندما يفشل `ch_probe()` بعد استدعاء `ch_readconfig()`.
تم الإبلاغ عن نفس التسرب (leak) مع طلب سحب RFC في عام 2022، والذي لم يتم دمجه.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.