CVE-2026-99207 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
scsi: target: تعطيل المقاطعات أثناء الاحتفاظ بـ delayed_cmd_lock
تأخذ دالة `target_do_delayed_work()` القفل `dev->delayed_cmd_lock` باستخدام `spin_lock()` عادي. تعمل هذه الدالة من خلال `system_percpu_wq`، وبالتالي تظل المقاطعات مفعّلة بينما يتم الاحتفاظ بالقفل. كل عملية أخرى لاقتناء هذا القفل تستخدم `spin_lock_irqsave()`: وهي `target_handle_task_attr()` و `transport_complete_ordered_sync()` في الملف `target_core_transport.c`، بالإضافة إلى `target_non_ordered_release()` في الملف `target_core_device.c`.
كانت هذه الحالة آمنة طالما أن كل متّصل لـ `transport_complete_task_attr()` يعمل في سياق العملية (process context): وهي `target_complete_ok_work()` من `target_completion_wq`، و `transport_complete_qf()` من `dev->qf_work_queue`، و `transport_generic_request_failure()` من مسارات الإرسال والتنفيذ.
منذ الالتزام 06933066d88a ("scsi: target: إضافة دعم لإكمال الأوامر من سياق الخلفية/الواجهة الخلفية") لم يعد هذا صحيحًا. مع ضبط `complete_type=1` على واجهة (fabric) تُعدّ `direct_compl_supp`، تعمل دالة `target_complete()` على استدعاء `target_complete_ok_work()` بشكل مضمن في سياق إكمال الواجهة الخلفية، وهو ما توثقه الدالة `target_complete_cmd_with_sense` بأنه "قد يتم استدعاؤها من سياق المقاطعة". بالنسبة إلى iblock، فإن ذلك يمثل نهاية bio (bio end_io).
تبدأ دالة `target_complete_ok_work()` باستدعاء `transport_complete_task_attr()`، والتي تأخذ القفل `delayed_cmd_lock》 بطريقتين:
- كل أمر ORDERED يتم وضعه في قائمة `dev->delayed_cmd_list` بواسطة `target_handle_task_attr()` ويتم إرساله من هناك بواسطة `target_do_delayed_work()`، والذي يحدد له علامة SCF_TASK_ORDERED_SYNC. وبالتالي فإن إكماله يمر عبر `transport_complete_ordered_sync()`.
- أمر SIMPLE الذي يكمل بينما يوجد أمر ORDERED معلق يُقلل المرجع الأخير إلى `dev->non_ordered` المُقتَل، وتقوم دالة `percpu_ref_put()` بعد ذلك بتشغيل `target_non_ordered_release()` في سياق الإكمال.
كلا الطريقتين تأخذان القفل، وإذا كانت هناك أوامر تنتظر، تستدعي `schedule_work(&dev->delayed_cmd_work)`، مما يضع العمل على قائمة الانتظار في `system_percpu_wq`، أي على المعالج الذي قام بعملية الإكمال. عمليات الإكمال الإضافية لنفس قائمة الانتظار تُقدَّم عادةً أيضًا هنا، لذا فإن وصول أحدها بينما يحتفظ العمل بالقفل يؤدي إلى دوران (spin) عليه للأبد.
الوصول إلى هذا الوضع يتطلب `complete_type=1`، وهو ليس القيمة الافتراضية (vhost-scsi هي الواجهة الوحيدة التي تدعم direct_compl_supp، وتستخدم افتراضيًا TARGET_QUEUE_COMPL)، وهي واجهة خلفية تكمل عمليات I/O من سياق المقاطعة، وأوامر ORDERED من المبادِل. ترسل عملاء Linux virtio_scsi فقط VIRTIO_SCSI_S_SIMPLE ولا تستخدم المسار المرتب (ordered path)؛ وأي عميل يستخدم سمة المهمة ORDERED، والتي يقبلها vhost-scsi، يفعل ذلك.
تُعد `target_do_delayed_work()` عنصر عمل وتعمل دائمًا في سياق العملية، لذا فإن استخدام `spin_lock_irq()` كافٍ.
تم العثور عليها عن طريق الفحص اليدوي (inspection)؛ ولا يوجد تقرير تشغيلي (runtime report). تمر أمر ORDERED واحد عبر عمليتي الاقتناء هاتين، لذا مع تفعيل CONFIG_PROVE_LOCKING يجب أن ينتج الاقتناء الأول الذي يكمل بشكل مباشر تقريرًا بحالة قفل غير متسقة على delayed_cmd_lock (hardirq أو softirq، اعتمادًا على مكان إكمال الواجهة الخلفية).
Be aware that VulDB is the high quality source for vulnerability data.