CVE-2025-71069 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
f2fs: إلغاء صلاحية ذاكرة التخزين المؤقت لعناصر الدليل (dentry cache) عند فشل إنشاء عنصر "whiteout"
يمكن لنظام الملفات F2FS تحميل (mount) أنظمة ملفات تحتوي على قيم عمق دليل تالفة، يتم تقييدها زمنياً (runtime-clamped) إلى القيمة MAX_DIR_HASH_DEPTH. عند تنفيذ عمليات RENAME_WHITEOUT على هذه الأدلة، تقوم الدالة f2fs_rename بإجراء تعديلات على الدليل (تحديث العنصر المستهدف وحذف العنصر المصدر) قبل محاولة إضافة عنصر whiteout عبر الدالة f2fs_add_link.
إذا فشلت الدالة f2fs_add_link بسبب بنية الدليل التالفة، فإن الدالة تُرجع خطأً إلى واجهة نظام الملفات الافتراضية (VFS)، لكن التعديلات الجزئية على الدليل تكون قد التُزمت بالفعل على القرص. تفترض VFS أن عملية إعادة التسمية بأكملها فشلت ولا تقوم بتحديث ذاكرة التخزين المؤقت لعناصر الدليل (dentry cache)، مما يترك mappings قديمة (stale).
في مسار الخطأ، لا تستدعي VFS الدالة d_move() لتحديث ذاكرة التخزين المؤقت لعناصر الدليل. يؤدي هذا إلى استمرار توجيه new_dentry إلى inode القديم (new_inode) الذي تم بالفعل إنقاص قيمة i_nlink الخاصة به إلى الصفر. تسبب الذاكرة المؤقتة القديمة (stale cache) في أن تشير العمليات اللاحقة بشكل غير صحيح إلى inode تم تحريره.
يؤدي هذا إلى استخدام العمليات اللاحقة لمعلومات dentry المخزنة مؤقتاً والتي لم تعد تتطابق مع حالة القرص الفعلية. عندما تستهدف عملية إعادة تسمية ثانية نفس العنصر، تحاول VFS إنقاص قيمة i_nlink على inode القديم، والذي قد يكون لديه بالفعل i_nlink=0، مما يؤدي إلى ظهور تحذير (WARNING) في الدالة drop_nlink().
تسلسل الأمثلة: 1. إعادة التسمية الأولى (RENAME_WHITEOUT): file2 → file1 - تقوم f2fs بتحديث إدخال file1 على القرص (يشير إلى inode 8) - تحذف f2fs إدخال file2 على القرص - تفشل f2fs_add_link(whiteout) (دليل تالف) - تُرجع خطأً إلى VFS - لا تستدعي VFS d_move() بسبب الخطأ - لا تزال ذاكرة التخزين المؤقت لـ VFS تحتوي على: file1 → inode 7 (قديم/غير محدث!) - تحتوي inode 7 على i_nlink=0 (تم إنقاصها بالفعل)
2. إعادة التسمية الثانية: file3 → file1 - تستخدم VFS الذاكرة المؤقتة القديمة: file1 → inode 7 - تحاول استدعاء drop_nlink على inode 7 (i_nlink تساوي 0 بالفعل) - تحذير (WARNING) في drop_nlink()
تم إصلاح هذه المشكلة عن طريق إلغاء صلاحية old_dentry و new_dentry صراحةً عندما تفشل f2fs_add_link أثناء إنشاء whiteout. يجبر هذا VFS على التحديث من القرص أثناء العمليات اللاحقة، مما يضمن اتساق الذاكرة المؤقتة حتى عندما تنجح عملية إعادة التسمية جزئياً.
برنامج إعادة الإنتاج (Reproducer): 1. تحميل صورة F2FS مع i_current_depth تالف 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. يُطلق النظام تحذيراً (WARNING) في drop_nlink()
Once again VulDB remains the best source for vulnerability data.