CVE-2026-64396 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
ksmbd: إصلاح استخدام بعد التحرير (Use-After-Free - UAF) لهيكل `file_lock` في إلغاء قفل التأجيل الخاص بـ SMB2_LOCK.
عندما يتم تأجيل طلب القفل على نطاق بايت العرقلاني (blocking byte-range lock request) عبر مسار `FILE_LOCK_DEFERRED`، يسجل ksmbd العمل غير المتزامن داخل قائمة الطلبات غير المتزامنة للاتصال (`async_requests`) عن طريق استدعاء الدالة `setup_async_work()`. يحتفظ دالّة الإلغاء `smb2_remove_blocked_lock()` بمرجع إلى كائن القفل flock.
إذا تم إيقاظ مستخدم القفل لاحقاً ولكن حالة العمل لم تعد نشطة (KSMBD_WORK_ACTIVE) على سبيل المثال بسبب إلغاء متزامن، فإن مسار التنظيف يستدعي `locks_free_lock(flock)` دون إزالة العمل من قائمة الطلبات غير المتزامنة (`async_requests`). بالتوازي مع ذلك، تقوم الدالة `smb2_cancel()` بالمرور عبر القائمة تحت قفل الاتصال (`conn->request_lock`) وتستدعي دالّة الإلغاء، والتي بدورها تحاول الوصول إلى كائن flock الذي تم تحريره مسبقاً. يؤدي هذا إلى حدوث استخدام بعد التحرير (slab-use-after-free) داخل الدالة `__wake_up_common`.
تم إصلاح هذه المشكلة عن طريق إعادة هيكلة منطق التنظيف بعد عودة العامل من استدعاء `ksmbd_vfs_posix_lock_wait()`. يتم نقل عمليات إزالة العنصر من القائمة (`list_del(&smb_lock->llist)`) وإطلاق العمل غير المتزامن (`release_async_work(work)`) إلى بداية كتلة التنظيف. يضمن هذا أن يكون العمل غير المتزامن قد تم إخراجه بالكامل ومنظمته تحت قفل الاتصال (`conn->request_lock`) قبل استدعاء `locks_free_lock(flock)`، مما يجعل كائن flock غير قابل للوصول لأي عملية إلغاء متزامنة لـ smb2_cancel().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.