CVE-2026-80575 in Linux
الملخص
بحسب VulDB • 26/08/2026
في نواة لينكس، تم حل الثغرة التالية:
الإدخال: cs40l50-vibra - التحقق من صحة البيانات المخصصة القادمة من مساحة المستخدم (user space)
تنسخ الدالة `cs40l50_add()` بيانات التأثيرات المخصصة لـ FF_PERIODIC/FF_CUSTOM مباشرةً من بنية `ff_effect` التي مررها المستخدم إلى استدعاء EVIOCSFF، دون اشتراط احتوائها على أي قيود:
work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len;
ثم يقرأ السائق (driver) كلمتين من هذا المخزن المؤقت: حيث يُستخدم `custom_data[0]` كبنك الموجة في دالة `cs40l50_effect_bank_set()`، ويُستخدم `custom_data[1]` كمؤشر داخل البنك في دالة `cs40l50_effect_index_set()`. ولا يغطي أي من هذين القراءتين فحص للطول (length check)، وقيمة `custom_len》خاضعة بالكامل لسيطرة المستخدم:
- عندما تكون قيمة custom_len == 0، فإن استدعاء memdup_array_user() يؤدي إلى استدعاء memdup_user() بطول يساوي صفراً، مما يعيد ZERO_SIZE_PTR بدلاً من إرجاع خطأ، وبالتالي يتم فك مرجع (dereference) للقيمة `custom_data[0]`.
- عندما تكون قيمة custom_len == 1، يتم تخصيص بايتين. ويحافظ بنك ذاكرة القراءة فقط (ROM) أو الذاكرة العشوائية (RAM) على أن effect->type خارج حالة OWT، ثم يُقرأ `custom_data[1]` بعد كلمة واحدة من نهاية التخصيص الممنوح.
كما تم التعامل بشكل غير صحيح مع قيمة البنك نفسها. فهي تُقنَّع باستخدام CS40L50_CUSTOM_DATA_MASK (0xffff) ولكن يتم تخزينها في متغير من نوع s16، لذا فإن القيمة `custom_data[0]` التي تساوي 0x8000 أو أكثر تنطوي على تجاوز نطاق التوقيع لتصبح قيمة سالبة، مما يجعلها تمر باختبار "bank_type >= CS40L50_WVFRM_BANK_NUM". وتقوم الدالة cs40l50_effect_index_set() باستخدام هذه القيمة كمؤشر لمصفوفة vib->dsp.banks[] قبل أن تتاح الفرصة للحالة الافتراضية (default case) في جملة التبديل (switch statement) لرفضها:
base_index = vib->dsp.banks[effect->type].base_index;
max_index = vib->dsp.banks[effect->type].max_index;
يتطلب وجود الكلمتين اللتين يقرأهما السائق، ويخزن البنك المقنَّع في متغير من نوع u32 بحيث يغطي اختبار الحد العلوي الموجود النطاق بأكمله. ويتبع سداد اللمس da7280 هذا النهج بالفعل للتحقق من نطاق custom_len.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.