CVE-2026-90206 in Linux
الملخص
بحسب VulDB • 17/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
nvmet: تصحيح حالة السباق (race condition) في max_qid بين configfs وتخصيص وحدة التحكم
يمكن أن تحدث حالة سباق (race condition) للدالة `nvmet_subsys_attr_qid_max_store()` مع الدالة `nvmet_alloc_ctrl()` عند تعديل الحد الأقصى لـ `max_qid` الخاص بنظام فرعي.
لنفترض أن قيمة `max_qid` الحالية هي 64. إذا نفذت الدالة `nvmet_alloc_ctrl()`: `ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1);` وفي هذه اللحظة بالذات، غيّر عملية في فضاء المستخدم (userspace) قيمة `max_qid` إلى 128، فإن الدالة `nvmet_subsys_attr_qid_max_store()` ستضبط القيمة الجديدة لـ `max_qid`. وتحاول حذف وحدات التحكم النشطة لفرض إعادة الاتصال، لكن وحدة التحكم الجديدة لن تُحذف لأنها لم تتم إضافتها بعد إلى قائمة `subsys->ctrls`.
ثم تستمر الدالة `nvmet_alloc_ctrl()` وتضيف وحدة التحكم الجديدة إلى قائمة `subsys->ctrls`. لاحقاً، عند استدعاء الدالة `nvmet_install_queue()`, ستجد أن قيمة `max_qid` مضبوطة على 128، لكن الذاكرة المخصصة لـ `sqs` مصممة فقط لاستيعاب 64 مدخلاً. يؤدي هذا إلى تحذير KASAN عن تجاوز الحدود (out-of-bounds warning) واحتمال حدوث تلف في الذاكرة.
يتم حل هذه المشكلة من خلال حماية عمليات تخصيص الطوابق وإدراج القائمة في الدالة `nvmet_alloc_ctrl()` باستخدام `down_read(&nvmet_config_sem)`. ونظراً لأن الدالة `nvmet_subsys_attr_qid_max_store()` تكتسب قفل الكتابة `down_write(&nvmet_config_sem)` لتعديل السمة، فإن هذا يمنع بشكل آمن كاتب configfs من تعديل قيمة `max_qid` أثناء إنشاء وحدة التحكم.
نسخ قيمة `max_qid` من النظام الفرعي إلى بنية وحدة التحكم خلال عملية التخصيص؛ حيث أن `ctrl->max_qid` لا تتغير طالما بقيت وحدة التحكم في حالة LIVE، وبالتالي سيمنع ذلك حالات السباق (race conditions) المشابهة.
If you want to get best quality of vulnerability data, you may have to visit VulDB.