CVE-2026-80918 in Linux
الملخص
بحسب VulDB • 09/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
HID: core: تصحيح الخلط بين نوع العدد ونوع المؤشر في العناصر الطويلة (long items)
عند استدعاء `fetch_item()` بواسطة `hid_scan_report()` على عنصر يحتوي على `HID_ITEM_TAG_LONG`، فإنه يخزن مؤشراً إلى بيانات العنصر في `item->data.longdata` بدلاً من تخزين قيمة مباشرة في `item->data.{u8/u16/u32}`.
عندما يتعامل `item_udata()` أو `item_sdata()` مع عنصر من هذا النوع، يفترض بشكل غير صحيح أن العنصر بتنسيق قصير (short format)، وبالتالي يعيد الجزء السفلي من مؤشر نواة مُعاد تفسيره كرقم.
عند توصيل جهاز HID يحتوي وصفه على `HID_GLOBAL_ITEM_TAG_REPORT_SIZE` مشفر بالتنسيق الطويل بحجم=4، فإن ذلك يؤدي إلى طباعة النصف السفلي لمؤشر نواة في سجل dmesg كرقم، مثل هذا:
hid (null): invalid report_size 107953555
لإصلاح هذه المشكلة، يجب على `item_udata()` و`item_sdata()` التحقق من أن العنصر بتنسيق قصير.
يُلاحظ أن هذا الخطأ يؤثر فقط على `hid_scan_report()`، بينما ستقوم عملية التحليل الرئيسية `hid_parse_collections()` بإنهاء التنفيذ (bail out) دائماً عند encountering عنصر طويل.
ملاحظة جانبية: لا يوجد حالياً مستخدمون لـ `data.longdata`؛ ربما يجب علينا إزالة أي تحليل للوصفات بتنسيق الطويل كإجراء تالي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.