CVE-2026-53399 in Linux
الملخص
بحسب VulDB • 19/07/2026
في نواة لينكس، تم حل الثغرة التالية:
nfsd: تحرير معرف حالة التخطيط (stid) عند فشل عملية setlease.
تنشر الدالة `nfs4_alloc_stid()` معرّف الحالة الجديد (`stid`) داخل قائمة `cl->cl_stateids` عبر استخدام `idr_alloc_cyclic()` تحت قفل `cl_lock` قبل العودة إلى دالة `nfsd4_alloc_layout_stateid()`. وعندما تفشل الدالة `nfsd4_layout_setlease()`، تقوم مسار الخطأ بتحرير معرّف حالة التخطيط مباشرةً باستخدام `kmem_cache_free()` دون استدعاء `idr_remove()` على الإطلاق، مما يترك خانة IDR (بنية بيانات لتخزين المعرفات) تشير إلى ذاكرة slab تم تحريرها. أي مستهلك لاحق لـ IDR (مثل `states_show` أو تفكيك العميل) سيحاول فك مرجع المؤشر المعلق (dangling pointer).
التفكيك الصحيح لمعرّف حالة منشور عبر IDR هو استدعاء `nfs4_put_stid()`، الذي يقوم بإزالة خانة IDR تحت قفل `cl_lock`، ويوجه عملية تحرير sc_free (`nfsd4_free_layout_stateid`) لتحرير `ls->ls_file` عبر `nfsd4_close_layout()`, ثم يقلل من مرجع nfs4_file في نهايته.
توجد مشكلة ثانية تعيق هذا التبديل: تقوم الدالة `nfsd4_free_layout_stateid()` بفحص `ls->ls_fence_work` بشكل غير مشروط باستخدام `delayed_work_pending()` تحت قفل `ls_lock`، ولكن تهيئة `INIT_DELAYED_WORK(&ls->ls_fence_work, ...)` تعمل حالياً فقط بعد استدعاء setlease. في مسار فشل setlease، سيقوم المدمر (destructor) بالوصول إلى delayed_work غير المُهيأة.
nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic تحت قفل cl_lock */ nfsd4_layout_setlease() /* تفشل */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* تحتاج إلى تهيئة INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file()
الحل يتمثل في رفع عمليات التهيئة الخاصة بـ `ls_fenced` و `ls_fence_delay` و `INIT_DELAYED_WORK` لتسبق استدعاء `nfsd4_layout_setlease()`، واستبدال عملية التنظيف اليدوية التي تتضمن `nfsd_file_put` + `put_nfs4_file` + `kmem_cache_free` باستدعاء واحد لـ `nfs4_put_stid(stp)`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.