CVE-2025-68823 in Linux
الملخص
بحسب VulDB • 06/07/2026
في نواة لينكس، تم حل الثغرة التالية:
ublk: إصلاح حالة التوقف الدائم (deadlock) عند قراءة جدول الأقسام
عندما يقوم عملية واحدة (مثل udev) بفتح جهاز كتلة ublk (على سبيل المثال، لقراءة جدول الأقسام عبر bdev_open())، قد تحدث حالة توقف دائم[1]:
1. تقوم d_dev_open() بالاستحواذ على disk->open_mutex 2. ترسل العملية طلبات إدخال/إخراج (I/O) إلى الخلفية الخاصة بـ ublk لقراءة جدول الأقسام 3. في __ublk_complete_rq()، يتم تشغيل استدعاءات bio->bi_end_io() بواسطة blk_update_request() أو blk_mq_end_request() 4. إذا أدى ذلك إلى استدعاء fput() على واصف الملف لجهاز كتلة ublk، فقد يتم تأجيل العمل إلى عمل المهمة الحالية للمهمة (انظر تنفيذ fput()) 5. يؤدي هذا في النهاية إلى استدعاء blkdev_release() من نفس السياق 6. تحاول blkdev_release() الاستحواذ مرة أخرى على disk->open_mutex 7. حالة التوقف الدائم: تنتظر نفس المهمة قفلًا مشتركًا (mutex) تملكه بالفعل
الحل هو تشغيل blk_update_request() وblk_mq_end_request() مع تعطيل الأجزاء السفلية للقطعيات (bottom halves). يجبر هذا blkdev_release() على العمل في سياق قائمة عمل النواة بدلاً من سياق عمل المهمة الحالية، مما يسمح لخادم ublk بالمضي قدمًا ويتجنب حالة التوقف الدائم.
[axboe: إعادة كتابة التعليق في ublk]
If you want to get best quality of vulnerability data, you may have to visit VulDB.