CVE-2026-99202 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
scsi: libsas: إصلاح حالة الجمود (Deadlock) في عمليات IO الخاصة بـ SMP أثناء استئناف وحدة التحكم المضيف (HA resume).
تقوم الدالة `smp_execute_task_sg()` باستدعاء `pm_runtime_get_sync()` على المضيف قبل إصدار أمر SMP. وعندما يتم إصدار هذا الأمر نفسه من مسار استئناف الـ HA، يحدث جمود: حيث تنتظر دالة `get_sync()` اكتمال عملية الاستئناف الجارية (حيث تكون حالة الجهاز RPM_RESUMING)، بينما تتوقف عملية الاستئناف في `sas_drain_work()` بانتظار اكتمال نفس عملية IO الخاصة بـ SMP.
تحتاج حالة الجمود هذه إلى قرص SATA متصل عبر موسع (expander). أثناء تنفيذ `sas_resume_ha() -> sas_drain_work()`، ينتقل وضع DISCE_RESUME إلى `sas_resume_sata()` ثم `ata_sas_port_resume()` لطلب عملية إعادة تعيين ATA_EH_RESET، وتتم عملية إعادة التعيين الصلبة لهذا القرص عبر SMP PHY CONTROL (من خلال تسلسل: `sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()`). أما عمليات إعادة التعيين لأقراص SATA المرفقة مباشرةً فتعتمد على `lldd_control_phy()`، وتستخدم الأجهزة SSP رسائل إدارة المهمة (TMFs)، لذا فإن أيًا منها لا يسبب هذه الحالة من الجمود.
استبدل زوج الدالتين `get_sync()/put_sync()` بالدالتين `pm_runtime_get_noresume()/pm_runtime_put()`. تحتاج دالة `smp_execute_task_sg()` فقط إلى منع التعليق التلقائي (autosuspend) أثناء تنفيذ أمر SMP، ولا يجب أن تحاول استئناف المضيف: فإصدار عملية استزام متزامن من مسار استئناف الـ HA نفسه هو ما يسبب الجمود، وبحلول وقت تشغيل `sas_resume_ha()`، تكون `hw_init` قد أعدت تهيئة العتاد بالفعل، لذا يكون الجهاز قابلاً للوصول دون الحاجة إلى ذلك الاستئناف.
لا تزال مرجعية الاستخدام مطلوبة. تعمل عمليات الاكتشاف عادةً داخل مرجع إدارة الطاقة (PM reference) الخاص بـ worker للأحداث، والذي يُؤخذ عند إشعار `sas_notify_port_event()` ويبقى ساريًا حتى يقوم المعالج بتفريغ قائمة الاكتشاف. ومع ذلك، تعيد دالة `sas_rediscover_ex_phy()` جدولة DISCE_REVALIDATE_DOMAIN من داخل عامل التحقق نفسه، ولا تنتظر دالة `flush_workqueue()` العناصر التي تم جدولتها أثناء التنفيذ، لذا فإن عمليات التحقق المتسلسلة تعمل دون مرجع PM خارجي - وبدون استخدام `get_noresume`، قد تتنافس عملية SMP مع التعليق التلقائي (autosuspend).
بالنسبة لمسار BSG، تُعد دالة `sas_smp_handler()` المتصل الوحيد الذي قد يجد المضيف في حالة تعليق تلقائي: لأن طلبات SMP الخاصة بالموسع لا تمر عبر أي قائمة طلبات لجهاز SCSI، لذا فلا شيء آخر في ذلك المسار يبقي المضيف مستيقظًا. قم باستئنافه هناك باستخدام `pm_runtime_resume_and_get()` وتحقق من النتيجة.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.