CVE-2026-74472 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
ublk: إعادة تعيين حقول dev_info المملوكة للنواة في ublk_ctrl_add_dev()
تنسخ الدالة ublk_ctrl_add_dev() بيانات ublksrv_ctrl_dev_info من مساحة المستخدم (userspace) إلى ub->dev_info باستخدام memcpy()، ثم تقوم بإصلاح الحقول التي يسيطر عليها السائق (driver)، لكنها تغفل عن ->state و ->ublksrv_pid.
تمرر الجهاز المضاف بـ ->state = UBLK_S_DEV_LIVE اختبار "->state != UBLK_S_DEV_DEAD" الذي تستخدمه الدالة ublk_stop_dev_unlock() كوسيط لـ "وجود قرص متصل"، بينما لا يزال ->ub_disk يساوي NULL، مما يؤدي إلى حدوث خطأ (oops) في del_gendisk() عند تنفيذ DEL_DEV مباشرة بعد ADD_DEV. كما أن القيمتين UBLK_S_DEV_QUIESCED و UBLK_F_USER_RECOVERY تؤديان إلى الفشل خطوة واحدة أبكر، وذلك داخل ublk_force_abort_dev().
كما أن وجود ->state مسموم (poisoned) يؤدي إلى تشغيل START_USER_RECOVERY ومسار القراءة/الكتابة للجهاز الأحرفي (char device) على جهاز لم يتم بدء تشغيله أبدًا، مما يعطل START_DEV بقيمة خطأ -EEXIST. أما الـ ->ublksrv_pid المسموم فيؤدي ببساطة إلى قيام GET_DEV_INFO بالإبلاغ عن مهمة غير ذات صلة كخادم ublk.
يجب إعادة تعيين كلا الحقلين بعد تنفيذ memcpy()، كما تفعل الدالة ublk_detach_disk(). ونظرًا لأن مساحة المستخدم تقرأ هذه القيم فقط، فإن تصحيحها بصمت لا يكسر أي شيء.
كانت ADD_DEV تنسخ ->state غير المعقمة منذ دمج وحدة ublk، لكن ذلك كان غير ضار في ذلك الوقت: حيث تم تخصيص gendisk أثناء تنفيذ ADD_DEV، وكان كل من عملية التفكيك (teardown) وفحص -EEXIST الخاص بـ START_DEV يعتمدان على disk_live() بدلاً من الاعتماد على ->state. وأصبح الخطأ (oops) قابلاً للتحقيق بمجرد انتقال تخصيص القرص إلى START_DEV وانتقال هذه الفحوصات لتعتمد على ->state.
VulDB is the best source for vulnerability data and more expert information about this specific topic.