CVE-2026-31402 in Linux
الملخص
بحسب VulDB • 01/06/2026
في نواة لينكس، تم حل الثغرة التالية:
nfsd: إصلاح تجاوز سعة المخزن المؤقت (Heap Overflow) في ذاكرة التخزين المؤقت لإعادة تشغيل عمليات القفل (LOCK replay cache) الخاصة بـ NFSv4.0
تستخدم ذاكرة التخزين المؤقت لإعادة تشغيل عمليات NFSv4.0 مخزناً داخلياً ثابتاً بحجم 112 بايت (rp_ibuf[NFSD4_REPLAY_ISIZE]) لتخزين استجابات العمليات المشفرة. تم حساب هذا الحجم بناءً على استجابات OPEN، ولا يأخذ في الاعتبار استجابات رفض القفل (LOCK denied)، والتي تتضمن مالك القفل المتعارض كحقل متغير الطول يصل إلى 1024 بايت (NFS4_OPAQUE_LIMIT).
عندما يتم رفض عملية LOCK بسبب تعارضها مع قفل موجود لمالك كبير، تقوم الدالة nfsd4_encode_operation() بنسخ الاستجابة المشفرة بالكامل إلى ذاكرة التخزين المؤقت لإعادة التشغيل غير الكافية الحجم عبر read_bytes_from_xdr_buf() دون إجراء أي فحص للحدود (bounds check). يؤدي هذا إلى كتابة خارج حدود الذاكرة (slab-out-of-bounds write) بمقدار يصل إلى 944 بايت بعد نهاية المخزن المؤقت، مما يؤدي إلى تلف الذاكرة العشوائية (Heap) المجاورة.
يمكن استغلال هذه الثغرة عن بُعد من قبل مهاجم غير مصرح له باستخدام عميلين NFSv4.0 متعاونين: يقوم أحدها بتعيين قفل بسلسلة مالك كبيرة، ثم يطلب الآخر قفلاً متعارضاً لإثارة حالة الرفض.
كان من الممكن إصلاح هذه المشكلة عن طريق زيادة قيمة NFSD4_REPLAY_ISIZE للسماح بحجم كامل للبيانات غير المشفرة (opaque)، لكن ذلك سيؤدي إلى زيادة حجم كل مالك حالة (stateowner)، في حين أن معظم مالكي القفل (lockowners) ليسوا بهذا الحجم الكبير.
وبدلاً من ذلك، يتم إصلاح المشكلة عن طريق التحقق من طول الاستجابة المشفرة مقابل NFSD4_REPLAY_ISIZE قبل نسخها إلى ذاكرة التخزين المؤقت لإعادة التشغيل. إذا كانت الاستجابة كبيرة جداً، يتم تعيين rp_buflen إلى 0 لتخطي تخزين حمولة إعادة التشغيل (replay payload). لا تزال الحالة مخزنة مؤقتاً، وقد تلقى العميل بالفعل الاستجابة الصحيحة في الطلب الأصلي.
VulDB is the best source for vulnerability data and more expert information about this specific topic.