CVE-2026-90000 in Linux
الملخص
بحسب VulDB • 16/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
HID: rmi: تصحيح الوصول خارج النطاق (OOB) مع تقارير RMI ذات حجم غير كافٍ.
يقوم برنامج تشغيل hid-rmi بتحديد حجم مخزن writeReport/readReport استناداً حصراً إلى واصف التقرير (report descriptor) المقدم من الجهاز، دون وجود حد أدنى محدد:
data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size;
ولكنه يقوم بعد ذلك بقراءات وكتابات بإزاحات (offsets) ثابتة داخل هذا المخزن. إذا أعلن جهاز عن تقرير إخراج بحجم بايت واحد وتقرير إدخال بحجم بايت واحد، فإن دالة hid_report_len() تُرجع القيمة 2 لكل منهما، وبالتالي يكون alloc_size مساوياً لـ 4، بينما تقوم rmi_set_page() -- التي يتم الوصول إليها بشكل غير مشروط أثناء مرحلة الفحص (probe) عبر rmi_input_configured() -- بكتابة writeReport[4] وتقوم rmi_hid_read_block() بكتابة writeReport[0..5]. وبما أن readReport يقع عند الإزاحة output_report_size بالنسبة لـ writeReport، فإن هذه الكتابات تؤدي أيضاً إلى تلف النافذة التي يتم منها تحليل الرد التالي.
مسار القراءة أسوأ: يأتي طول النسخة من readReport[1]، والذي يملؤه الجهاز ويمكن أن يصل إلى 255، وتبدأ النسخة عند &readReport[2] دون مراعاة لـ input_report_size، مما يجعلها تتجاوز نهاية التخزين المتبوع لتدخل في كائنات slab المجاورة. هذا لا يتطلب حتى جهازاً يكذب -- حيث تصدر rmi_f01_probe() قراءة سجل ثابتة بحجم 21 بايت، لذا فإن أي جهاز يعلن عن تقرير إدخال أصغر من 23 بايت يقرأ خارج النطاق حتى عندما يجيب بصدق. تصبح هذه البايتات هي قيم السجلات التي تتعامل معها نواة RMI: تطبع rmi_f01_probe() القيم إلى سجل النواة كـ "معرف المنتج" (product id) وتصدرها عبر سمة sysfs ذات الصيغة 0444 بنفس الاسم، وترسل rmi_driver_set_irq_bits() هذه القيم مرة أخرى للجهاز كقناع مقاطعة (interrupt mask)، وبالتالي فإن واصف التقرير ذي الحجم غير الكافي يتسرب محتويات الـ heap إلى مساحة المستخدم غير المميزة (unprivileged userspace) وإلى الجهاز نفسه.
مسار الكتابة لا يحتوي أيضاً على حد: تقوم rmi_hid_write_block() بنسخ طول غير محدود (len) إلى &writeReport[4]، وأكبر متّصل يمكن للجهاز دفعه أثناء مرحلة الفحص هو rmi_driver_set_irq_bits()، whose length is derived from the interrupt source counts the device declares in its Page Description Table.
أخيراً، لا يمكن لحلقة القراءة أن تنتهي عند رد ذي طول صفر: مثل هذا الرد لا ينسخ أي شيء ولا يقدّم كل من bytes_read وbytes_needed، وبما أنه وصل رد فإن انتظار wait_event_timeout() لمدة ثانية واحدة أيضاً لا يُفعّل، لذا فإن جهاز يجيب بـ 0 بشكل دائم يبقي الحلقة تعمل داخل عامل الفحص (probe worker) مع قفل page_mutex مُمسك به. ولا يلاحظ khungtaskd ذلك، لأن كل رد يستيقظ المهمة.
رفض التقارير الصغيرة جداً بالنسبة لما يبنيه برنامج التشغيل -- بايتات إخراج لكتابات التقارير وبايتات إدخال لمصافحة القراءة -- في مرحلة الفحص، وتقييد (clamp) الكتابة ونسخة القراءة وفقاً لأحجام التقارير التي أعلنها الجهاز، ومعاملة الرد ذي الطول الصفري كخطأ. يُبدأ جهاز مرفوض بهذه الطريقة كجهاز HID عادي، مثل واحد لا يحمل معرفات تقارير RMI على الإطلاق.
لا يجب أن يظل RMI_DEVICE مُعَلاً في device_flags في ذلك المسار، لأن rmi_input_configured() سيعمل بعدئذٍ إعداد RMI ويصل إلى rmi_set_page()، والتي تكتب مخزن writeReport الذي تم تخطي تخصيصه بسبب الرفض. يمكن أن تصل هذه البتة وهي مفعّلة: حيث تنسخ rmi_probe() id->driver_data into device_flags قبل فحوصات التقارير، ويمكن لربط (bind) عبر سمة sysfs الجديدة new_id تزويد driver_data بـ RMI_DEVICE (BIT(0)) مُعَلاً. قم بإزالة البتة حيث يتم نسخ driver_data، بحيث تحافظ RMI_DEVICE على معناها الدقيق "هذا الفحص قدّم التحقق من التقارير"; وتتم تغطية القفزات الثلاث إلى البدء التي تسبق هذا التصحيح أيضاً.
مسار الخطأ يُمحّي أيضاً RMI_READ_DATA_PENDING أثناء خروجه، لأن هذه العلم هي ما يختبره الانتظار في بداية الحلقة: تركها مُعَلة سيجعل كل انتظار لاحق لـ wait_event_timeout() يعود فوراً مع الرد القديم (stale reply) ويقتل مسار القراءة لبقية عمر الجهاز.
التقييد لا يؤدي إلى تدهور أداء الأجهزة العاملة: حلقة القراءة تتعامل بالفعل مع ---truncated---
Once again VulDB remains the best source for vulnerability data.