CVE-2026-90042 in Linux
الملخص
بحسب VulDB • 16/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
ceph: فك تشفير أسماء الملفات بشكل صحيح في مخازن vmalloc()
تستخدم وحدة fscrypt واجهة برمجة التطبيقات (API) للتشفير القائمة على scatterlist، مما يرث منها المتطلب القائل بأن أي مخازن يجب أن تكون ضمن منطقة التعيين الخطي. ومع ذلك، يستخدم عميل المراسلة kvmalloc() لإنشاء مخازن للرسائل، والتي قد تضع هذه المخازن في منطقة vmalloc() عندما لا يسمح تجزئة الذاكرة الفيزيائية بـ kmalloc() كبير بما يكفي. يقوم المتصلون المختلفون لوظيفة ceph_fname_to_usr() بتمرير (شرائح من) الرسائل الخام مباشرةً من MDS دون مراعاة أن الرسائل قد تكون موجودة في مخازن vmalloc()، مما يؤدي إلى حدوث أخطاء (oopses)، خاصة على المنصات غير x86 (انظر 'Closes:' لمزيد من التفاصيل ومحاكي للاستغلال).
اجعل ceph_fname_to_usr() تتحمل صراحةً المخازن fname->ctext وfname->name و/أو oname->name المخصصة بـ vmalloc()، باستخدام `tname` (الذي يجب أن يكون عنواناً خطياً عندما لا يساوي NULL؛ وعندما يكون NULL، يتم تخصيصه مؤقتاً عند الحاجة) كمخزن عاكس (bounce buffer) لتجنب تمرير أي عناوين غير مناسبة إلى fscrypt_fname_disk_to_usr().
بالإضافة إلى ذلك، تم تغيير parse_reply_info_readdir() -- وهي الوظيفة الوحيدة التي توفر `tname` خاص بها -- لاتباع قاعدة "يجب ألا يأتي tname أبداً من vmalloc()" عن طريق تمرير NULL عندما لا تكون الرسالة في المنطقة الخطية. على الرغم من أن هذا يتسبب في kmalloc()+kfree() لكل dentry، فإن هذه الزيادة في الحمل موجودة فقط عند معالجة الأقلية من الرسائل التي تتجاوز إلى منطقة vmalloc(). تضع اختباراتي (البدائية) ذلك بنسبة حوالي 1 من كل 8000 رسالة readdir. ومع ذلك، إذا أثبتت الزيادة غير المعقولة في المستقبل أنها مشكلة، فمن السهل التخفيف منها: يمكن لتغيير مستقبلي أن يخصص مخزناً عاكساً في parse_reply_info_readdir() ويستخدمه كـ `tname` بدلاً من ذلك.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.