CVE-2025-40303 in Linux
الملخص
بحسب VulDB • 30/05/2026
في نواة لينكس، تم حل الثغرة التالية:
btrfs: ضمان عدم كتابة أي بيانات وصفية (metadata) غير نظيفة مرة أخرى لنظام ملفات يحتوي على أخطاء
[الخطأ]
أثناء تطوير ميزة ثانوية (التأكد من استدعاء جميع دوال btrfs_bio::end_io() في سياق المهمة)، لاحظت حدوث انهيار في الاختبار generic/388، حيث أدت كتابات البيانات الوصفية إلى إنشاء مهام جديدة بعد استدعاء btrfs_stop_all_workers().
اتضح أنه يمكن أن يحدث ذلك حتى دون أي تعديل في الكود، فقط باستخدام RAID5 للبيانات الوصفية، فإن نفس الحمل الوظيفي من generic/388 سيؤدي إلى حدوث خطأ استخدام بعد التحرير (use-after-free).
[السبب]
إذا اصطدم btrfs بخطأ، يتم وضع علامة خطأ على نظام الملفات، ولا يُسمح بإجراء أي معاملات جديدة وبالتالي تكون البيانات الوصفية في حالة مجمدة.
ولكن هناك بعض التعديلات على البيانات الوصفية قبل حدوث هذا الخطأ، وهي لا تزال موجودة في ذاكرة التخزين المؤقت لصفحات عقدة شجرة البيانات (btree inode page cache).
بما أنه لن يكون هناك إكمال حقيقي للمعاملة، فإن جميع أوراق الصفحة (folios) غير النظيفة تبقى كما هي في ذاكرة التخزين المؤقت للصفحات، ولا يمكن إبطالها بواسطة استدعاء invalidate_inode_pages2() داخل close_ctree()، لأنها غير نظيفة.
وأخيراً، بعد استدعاء btrfs_stop_all_workers()، نقوم باستدعاء iput() على عقدة شجرة البيانات، مما يؤدي إلى إعادة كتابة تلك البيانات الوصفية غير النظيفة.
وإذا كان نظام الملفات يستخدم RAID56 للبيانات الوصفية، فإن هذا سيؤدي إلى تشغيل عمليات القراءة-التعديل-الكتابة (RMW) وإدخال مهام جديدة في rmw_workers، والتي تم إيقافها بالفعل، مما يسبب تحذيراً من queue_work() وخطأ استخدام بعد التحرير.
[الحل]
إضافة معالجة خاصة لـ write_one_eb()، بحيث إذا كان نظام الملفات في حالة خطأ بالفعل، يتم وضع علامة فشل على bbio على الفور، بدلاً من إرسالها فعلياً.
ثم أثناء close_ctree()، سيؤدي استدعاء iput() إلى تجاهل جميع كتل الشجرة غير النظيفة دون كتابتها فعلياً مرة أخرى، وبالتالي لا توجد مهام جديدة لمجموعات المهام التي تم إيقافها وتحريرها بالفعل.
يعمل تجاهل write_one_eb() الإضافي أيضاً كشبكة أمان إضافية. على سبيل المثال، يتم إحداث إلغاء المعاملة بسبب بعض تلف شجرة الامتدادات/المساحة الحرة، وبما أن شجرة الامتدادات/المساحة الحرة تالفة بالفعل، فقد يتم تخصيص كتل شجرة حيث لا ينبغي أن تكون (فوق كتابة كتل الشجرة الموجودة). في هذه الحالة، ستؤدي كتابتها مرة أخرى إلى مزيد من تلف نظام الملفات.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.