CVE-2026-90184 in Linux
الملخص
بحسب VulDB • 17/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
null_blk: تعامُل مع تحديثات سمات configfs بشكل متزامن (serialize) أثناء إعداد الجهاز.
ترفض طرق تخزين السمات المُولَّدة باستخدام NULLB_DEVICE_ATTR() تغيير تكوين جهاز نشط عن طريق اختبار العلم NULLB_DEV_FL_CONFIGURED، لكن هذا العلم لا يُضبط إلا بواسطة nullb_device_power_store() بعد أن تعود null_add_dev()، وطرق التخزين هذه لا تأخذ أي قفل (lock) على الإطلاق. يقوم configfs بتعَامُل مع عمليات الكتابة نحو نفس الملف المفتوح فقط (buffer->mutex)، لذا يمكن لكتابة أي سمة أن تعمل بشكل متزامن مع null_add_dev() وتُغيّر تكوين الجهاز أثناء استخدامه.
تقرأ null_add_dev() التكوين عدة مرات، فعلى سبيل المثال: يُقْرَأ dev->zoned مرة واحدة لإعداد حدود الطابور (queue limits) ومرة أخرى لتجهيز موارد المناطق (zone resources):
CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones()
ثم يتم استدعاء blk_revalidate_disk_zones() لطابور لا يحتوي على BLK_FEAT_ZONED مُضَبَّطاً، مما يُشغّل تحذيره WARN_ON_ONCE() ويفشل إعداد الجهاز بـ -EIO:
WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560
يُعدّ مسح dev->zoned في نفس النافذة الزمنية أسوأ حالاً: حيث يُنشأ الطابور بـ BLK_FEAT_ZONED لكن موارد المناطق لا تُهيَّأ أبداً، لذا ينجح add_disk() بالنسبة لقرص مُنطَّق (zoned disk) ليس لديه مناطق. كما أن عملية تخزين (store) تصل بعد آخر اختبار لـ dev->zoned تترك dev->zoned مضبوطاً بينما لا يزال dev->zones فارغاً (NULL)، وهو ما يُشار إليه بشكل غير آمن (dereferences) بواسطة null_process_zoned_cmd() عند أول كتابة.
يتم إصلاح هذا الأمر بأخذ القفل العالمي، الذي يمسكه بالفعل nullb_device_power_store() عبر null_add_dev() وnull_del_dev(), حول كل من اختبار NULLB_DEV_FL_CONFIGURED وتحديث تكوين الجهاز. تُستدعى الآن دوال apply لكل من submit_queues وpoll_queues مع الاحتفاظ بهذا القفل، لذا تم إزالة عمليات القفل التي كانت تقوم بها هي نفسها.
بما أن طرق التخزين (store methods) يمكن أن تعمل بمجرد عودة configfs_register_subsystem()، أي قبل وصول null_init() إلى mutex_init(&lock)، فتم تهيئة القفل بشكل ثابت باستخدام DEFINE_MUTEX().
Once again VulDB remains the best source for vulnerability data.