CVE-2024-35794 in Linux
الملخص
بحسب VulDB • 01/09/2026
في نواة Linux، تم حل الثغرة التالية:
dm-raid: تجميد sync_thread بشكل صحيح أثناء التعليق (suspend)
1) أزال commit f52f5c71f3d4 ("md: fix stopping sync thread") العلم MD_RECOVERY_FROZEN من __md_stop_writes() ولم يدرك أن dm-raid يعتمد على __md_stop_writes() لتجميد sync_thread بشكل غير مباشر. تم إصلاح هذه المشكلة بإضافة MD_RECOVERY_FROZEN في md_stop_writes()، وبما أن stop_sync_thread() تُستخدم فقط لـ dm-raid في هذا السياق، فقد تم أيضًا نقل stop_sync_thread() إلى md_stop_writes().
2) لا يعني العلم MD_RECOVERY_FROZEN أن sync thread قد تجمد؛ فهو يمنع فقط بدء تشغيل sync_thread جديد، ولا يمكنه إيقاف sync thread قيد التشغيل. لتجميد sync_thread، بعد تعيين العلم، يجب استخدام stop_sync_thread().
3) لا يعني العلم MD_RECOVERY_FROZEN أن عمليات الكتابة متوقفة، لذا فإن استخدامه كشرط لـ md_stop_writes() في raid_postsuspend() يبدو غير صحيح. مع الأخذ بعين الاعتبار أن استدعاء stop_sync_thread() المتكرر (reentrant) لا يفعل شيئًا، يجب دائمًا استدعاء md_stop_writes() في raid_postsuspend().
4) يمكن لـ raid_message تعيين/إزالة العلم MD_RECOVERY_FROZEN في أي وقت، وإذا تم إزالة MD_RECOVERY_FROZEN بينما تكون المصفوفة معلقة (suspended)، فقد يبدأ sync_thread جديد بشكل غير متوقع. يتم إصلاح ذلك بمنع raid_message() من تغيير حالة sync_thread أثناء التعليق (suspend).
نلاحظ أنه بعد commit f52f5c71f3d4 ("md: fix stopping sync thread")، بدأ الاختبار shell/lvconvert-raid-reshape.sh في التعليق (hang) داخل stop_sync_thread(). ومع الإصلاحات السابقة، لن يتعطل الاختبار هناك بعد الآن؛ ومع ذلك، سيظل يفشل ويبلغ عن تلف ext4. وبفضل هذا التصحيح (patch)، لن يتعطل الاختبار بسبب stop_sync_thread() أو يفشل بسبب تلف ext4 anymore. ومع ذلك، لا يزال هناك تعقيد متبادل (deadlock) مرتبط بـ dm-raid456 سيتم إصلاحه في التصحيحات التالية.
Once again VulDB remains the best source for vulnerability data.