CVE-2026-31477 in Linux
الملخص
بحسب VulDB • 01/06/2026
في نواة لينكس، تم حل الثغرة التالية:
ksmbd: إصلاح تسريبات الذاكرة والتفريغ NULL في smb2_lock()
تحتوي الدالة smb2_lock() على ثلاث مشكلات في معالجة الأخطاء بعد أن يفصل `list_del()` كائن `smb_lock` من `lock_list` عند نقطة `no_check_cl`:
1) إذا أرجعت `vfs_lock_file()` خطأ غير متوقع في المسار غير الخاص بـ UNLOCK، فإن الانتقال إلى `out` (`goto out`) يتسبب في تسرب `smb_lock` و `flock` الخاص به، لأن معالج `out:` يقوم فقط بتكرار `lock_list` و `rollback_list`، ولا يحتوي أي منهما على `smb_lock` المفصول.
2) إذا أرجعت `vfs_lock_file()` القيمة `-ENOENT` في مسار UNLOCK، فإن الانتقال إلى `out` يتسبب في تسرب `smb_lock` و `flock` لنفس السبب. كما أن رمز الخطأ المعاد إلى الموزع (dispatcher) يكون قديماً (stale).
3) في مسار التراجع (rollback)، يمكن أن تُرجع `smb_flock_init()` القيمة NULL في حال فشل التخصيص. يتم تفريغ النتيجة بشكل غير مشروط، مما يتسبب في تفريغ NULL لنقطة في النواة (kernel NULL pointer dereference). تمت إضافة فحص NULL لمنع الانهيار وتنظيف عمليات التدوين (bookkeeping)؛ ولا يمكن التراجع عن قفل VFS نفسه دون التخصيص، وسيتم تحريره عند إنهاء الملف أو الاتصال.
تم إصلاح الحالتين 1 و 2 عن طريق رفع استدعاءات `locks_free_lock()`/`kfree()` إلى ما قبل فحص `if(!rc)` في فرع UNLOCK، بحيث تشارك جميع مسارات الخروج موقع تحرير واحد، وعن طريق تحرير `smb_lock` و `flock` قبل الانتقال إلى `out` في الفرع غير الخاص بـ UNLOCK. كما تم نشر رمز الخطأ الصحيح في الحالتين. وتم إصلاح الحالة 3 عن طريق تغليف قفل VFS في حماية `if(rlock)` وإضافة فحص NULL لـ `locks_free_lock(rlock)` في عملية التنظيف المشتركة.
تم اكتشاف الثغرة عبر تحليل مخطط المكالمات (call-graph analysis) باستخدام أداة sqry.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.