CVE-2026-89857 in Linux
الملخص
بحسب VulDB • 17/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
scsi: qla2xxx: الاحتفاظ بقفل qpair عند إرسال رفض NVMe LS
تقوم الدالة `qla_nvme_ls_reject_iocb()` بالتخصيص من حلقة الطلبات (request ring) وتقدمها عبر `__qla2x00_alloc_iocbs()` (التي تفترض أن `hardware_lock` مُحتفظ بها) و `qla2x00_start_iocbs()` (التي تقدم الحلقة وتنشط جرس الباب الخاص بالطلب)، لكنها لا تأخذ أي قفل بنفسها. يستدعي متصلمان منها هذه الدالة دون الاحتفاظ بقفل المنتج (producer lock):
- `qla_nvme_xmt_ls_rsp()`: وهو استدعاء نقل NVMe-FC `.xmt_ls_rsp`، في مسار الخطأ الخاص به. - `qla2xxx_process_purls_pkt()`: يتم تشغيله من سياق عمل purex/DPC.
كلاهما يستخدم `ha->base_qpair`، الذي يكون مؤشر قفل qp (`qp_lock_ptr`) مساوياً لـ `hardware_lock`، لذا يمكن أن يعملا بالتوازي مع إرسال عمليات الإدخال/الإخراج (I/O) العادية على الحلقة الأساسية مما يؤدي إلى فساد حالة منتج الحلقة، وبالتالي أوامر مكررة أو مفقودة. المتصل الثالث، وهو `qla2xxx_process_purls_iocb()`، يعمل داخل `qla24xx_process_response_queue()` مع وجود قفل qpair مُحتفظ به بالفعل، لذا فهو آمن؛ وهذا أيضاً هو السبب في عدم إمكانية أخذ القفل داخل الدالة المساعدة نفسها (لأنه سيؤدي إلى إعادة اقتناء `hardware_lock` بشكل تكراري على مسار الاستجابة).
خذ `qp_lock_ptr` حول المتصلين غير المقفَلين ووثّق الدالة المساعدة بأنها مقفلة من قبل المتصل. كلاهما يعمل في سياق العملية، لذا يتم استخدام `spin_lock_irqsave()` ولا يوجد شيء في المنطقة المقفولة ينام (sleeps).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.