CVE-2026-45942 in Linux
الملخص
بحسب VulDB • 27/05/2026
في نواة لينكس، تم حل الثغرة التالية:
ext4: إصلاح تقارير عدم اتساق مخطط البتات (bitmap) لـ e4b
تم رصد مشكلة تتعلق بعدم اتساق مخطط البتات (bitmap) أثناء اختبارات الإجهاد تحت أحمال عمل مختلطة تتضمن صفحات ضخمة (huge-page). وقد أبلغ نظام الملفات ext4 عن فشل متعدد في فحوصات مخطط البتات لـ e4b، مثل:
ext4_mb_complex_scan_group:2508: المجموعة 350، تحتوي على 8179 عنقوداً (clusters) حراً وفقاً لمعلومات المجموعة. ولكن تم الحصول على 8192 كتلة (block).
أكدت التحليلات والتجارب أن المشكلة ناتجة عن حالة سباق (race condition) بين عملية نقل الصفحة (page migration) وتعديل مخطط البتات. وعلى الرغم من أن نافذة التوقيت هذه ضيقة للغاية، إلا أنها تحدث عملياً:
folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock
السبب الجذري لهذه المشكلة هو أن المسار السريع (fast path) في دالة load_buddy يقوم فقط بزيادة عداد الإشارات المرجعية (reference count) للعنقود (folio)، وهو أمر غير كافٍ لمنع نقل العنقود المتزامن. وقد لاحظنا أن عملية نقل العنقود تكتسب قفل العنقود (folio lock). لذلك، يمكننا تحديد ما إذا كان يجب اتباع المسار السريع في load_buddy من خلال التحقق من حالة القفل. إذا كان العنقود مقفلاً، فإننا نختار المسار البطيء (الذي يكتسب القفل) لإغلاق نافذة التزامن هذه.
بالإضافة إلى ذلك، يعالج هذا التغيير المشكلات التالية:
عند تفعيل ماكرو DOUBLE_CHECK لفحص المشكلات المتعلقة بمخطط البتات، قد يتم تشغيل الخطأ التالي:
corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc
يكشف التحليل أن هذا نتيجة إيجابية كاذبة (false positive). توجد نافذة سباق محددة حيث يصبح مخطط البت ووصف المجموعة غير متسقين لحظياً، مما يؤدي إلى هذا التقرير الخطأ:
ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock
افترض المنطق الأصلي أنه بما أن mb_cmp_bitmaps يتم استدعاؤها عندما يتم تحميل مخطط البت حديثاً من القرص، فإن قفل العنقود سيكون كافياً لمنع الوصول المتزامن. ومع ذلك، يتجاهل هذا حالة سباق محددة: إذا حاول عملية أخرى تحميل العنقود المساعد (buddy) ووجدت أن العنقود موجود بالفعل في حالة محدثة (uptodate)، فسيبدأ في استخدامه فوراً دون الاحتفاظ بقفل العنقود.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.