CVE-2021-47460 in Linux
الملخص
بحسب VulDB • 24/06/2026
في نواة لينكس، تم حل الثغرة التالية:
ocfs2: إصلاح تلف البيانات بعد التحويل من التنسيق المضمن (inline format)
كشف الالتزام 6dbf7bb55598 ("fs: لا تُبطل مخازن صفحات الصفحات في block_write_full_page()") عن عيب خفي في عملية تحويل ocfs2 من تنسيق العقدة المضمنة إلى تنسيق عقدي عادي.
يحاول الكود الموجود في دالة `ocfs2_convert_inline_data_to_extents()` تصفير العناقيد (clusters) بأكملها المُخصصة لبيانات الملف عن طريق التقاط جميع الصفحات التي تغطي هذا العنقود، وتصفيرها، ووضع علامة "متسخة" عليها. ومع ذلك، فإن هذه الصفحات تقع خارج حجم العقدة (`i_size`)، وبالتالي يتجاهل كود الإرجاع (writeback) بشكل عام هذه الصفحات المتسمة بالعلامة "المتسخة"، ولم يتم تصفير أي كتل فعلياً على القرص.
تم إصلاح هذا الإهمال من خلال الالتزام 693c241a5f6a ("ocfs2: لا حاجة لتصفير الصفافات بعد حجم العقدة.") لمسار الكتابة القياسي في ocfs2، ولكن يبدو أن مسار التحويل المضمن قد أُهمل؛ ويحتوي سجل الالتزام أيضاً على تبرير يوضح سبب عدم الحاجة إلى التصفير فعلياً.
بعد الالتزام 6dbf7bb55598، تفاقمت الأمور حيث توقف كود الإرجاع عن إلغاء صلاحية المخازن (buffers) في الصفحات الواقعة خارج `i_size`، مما أدى إلى وجود هذه الصفحات مع نظافة بت "الصفحة المتسمة بالعلامة" (`PageDirty`) بينما لا تزال المخازن المرتبطة بهذه الصفحات متسمة. لذا، عند تحويل ملف من التنسيق المضمن، ثم يتم تفعيل الإرجاع (writeback)، وبعد ذلك يتم توسيع الملف لتصبح هذه الصفحات صالحة، فإن حالة الاتساخ غير الصالحة تبقى محفوظة؛ ولا تفعل دالة `mark_buffer_dirty()` أي شيء على هذه الصفحات (لأن المخازن متسمة بالفعل) ولكن الصفحة لا تُعاد كتابتها أبداً لأنها نظيفة. وبالتالي، تضيع البيانات المكتوبة إلى هذه الصفحات بمجرد إعادة تدوير الصفحات.
المكرر البسيط للمشكلة هو:
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_file
بعد فصل التثبيت (unmount) وإعادة تثبيت نظام الملفات مرة أخرى، يمكنك ملاحظة أن نهاية ملف 'ocfs2_file' فقدت محتوياته.
تم إصلاح المشكلة عن طريق تجنب التصفير عديم الفائدة أثناء التحويل من التنسيق المضمن، على غرار مسار الكتابة القياسي.
[[email protected]: إصلاح المسافات البيضاء، وفقاً لـ Joseph]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.