CVE-2025-40105 in Linux
الملخص
بحسب VulDB • 24/05/2026
في نواة لينكس، تم حل الثغرة التالية:
vfs: عدم تسرب dentries غير المتصلة (disconnected) عند تنفيذ umount
عندما يستدعي المستخدم دالة `open_by_handle_at()` على عقدة (inode) غير موجودة في ذاكرة التخزين المؤقت، سيتم إنشاء dentry غير متصل (disconnected dentry) لها. إذا كان هذا الـ dentry مجلداً، فستحاول الدالة `exportfs_decode_fh_raw()` بعد ذلك ربط هذا الـ dentry بشجرة الـ dentries عبر دالة `reconnect_path()`. قد تفشل الدالة `lookup_one_unlock()` داخل `reconnect_one()` في العثور على الـ dentry الذي نحاول إعادة توصيله لأسباب مختلفة (مثل تلف نظام الملفات أو حالة سباق مع عملية rename)، وبدلاً من ذلك تقوم بإنشاء dentry جديد تحت المجلد الأب. الآن، لن يتم تحديد هذا الـ dentry على أنه غير متصل (disconnected) على الرغم من أن المجلد الأب قد يكون غير متصل بالفعل (على الأقل في حالة حدوث هذا التناقض بسبب تلف نظام الملفات وعدم указاء `..` إلى المجلد الأب الحقيقي). هذا يخلق تناقضاً في أعلام الـ disconnected، ولكن على حد علمي (AFAICS)، كان ذلك غير ضار في الغالب. على الأقل حتى الالتزام commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") الذي أزال إضافة معظم الـ dentries غير المتصلة إلى قائمة `sb->s_anon`. وبالتالي، بعد هذا الالتزام، يعتمد تنظيف الـ dentries غير المتصلة بشكل ضمني على حقيقة أن `dput()` ستقوم بإعادة استرداد (reclaim) هذه الـ dentries على الفور. ومع ذلك، عندما لا يتم تحديد بعض الـ dentries الورقية (leaf dentries) على أنها غير متصلة، كما في السيناريو الموصوف أعلاه، لا تحدث عملية الاسترداد، وتظل الـ dentries "مُسربة" في الذاكرة. يمكن لآلية استرداد الذاكرة في النهاية استردادها، ولكن بخلاف ذلك تظل في الذاكرة، وإذا جاءت عملية `umount` أولاً، فإننا نواجه ثغرة "Busy inodes after unmount" الشهيرة. تأكد من أن جميع الـ dentries التي تم إنشاؤها تحت مجلد أب غير متصل يتم تحديدها أيضاً على أنها غير متصلة.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.