CVE-2026-89714 in Linux
الملخص
بحسب VulDB • 11/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
NFS: تصحيح تسرب delegation_hash_table عند فشل nfs4_server_common_setup()
تقوم الدالة nfs4_server_common_setup() بتخصيص server->delegation_hash_table في البداية، لكن server->destroy - وهو المسار الوحيد الذي يحرر الجدول عبر nfs4_destroy_server() - لا يتم تعيينه إلا في نهاية الدالة تمامًا. إذا فشلت أي خطوة وسيطة (مثل فحص is_ds_only_client(), أو nfs4_init_session(), أو nfs4_get_rootfh(), أو nfs_probe_server())، فإن الدالة تعود مع بقاء server->destroy كـ NULL، وبالتالي يتخطى المتصل nfs_free_server() استدعاء التدمير (destroy callback)، مما يؤدي إلى تسرب الجدول الهاشي (بحجم 4 كيلوبايت لكل محاولة باستخدام حد الماء الافتراضي للتفويض).
يمكن الوصول إلى هذه الثغرة بسهولة من مساحة المستخدم: كل عملية تثبيت NFSv4 فاشلة تتسبب في تسبق تخصيص واحد. العميل الذي يعيد المحاولة بشكل مستمر لتثبيت لا يمكن أن ينجح يتسرب ذاكرة النواة دون حدود. لوحظ هذا في بيئة الإنتاج حيث كان جامع نسخ Longhorn يعيد محاولة mount.nfs4 ضد خادم يدعم فقط NFSv3 بحوالي 10 مرات في الثانية، مما تسبب في تسرب حوالي 3.4 جيجابايت من slab غير القابلة للاسترداد (kmalloc-rnd-13-4k) يوميًا؛ وتراكم العقدة 12 جيجابايت من slab المتسربة قبل تحديد المصدر عبر نقطة التتبع kmem:kmalloc (call_site=nfs4_delegation_hash_alloc).
معيد الإنتاج (Reproducer):
# الخادم يصدر NFSv3 فقط (أو مسار التصدير غائب لـ v4) while :; do mount -t nfs4 <server>:/missing /mnt; done # راقب SUnreclaim في /proc/meminfo وهو ينمو بمقدار 4 كيلوبايت لكل تكرار
تحرير الجدول على مسارات الخطأ بين التخصيص وتعيين server->destroy.
If you want to get best quality of vulnerability data, you may have to visit VulDB.