CVE-2026-80766 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
HID: uclogic: تصحيح استخدام الذاكرة بعد تحريرها (use-after-free) لـ inrange_timer عند الإزالة
تقوم دالة `uclogic_remove()` بإلغاء مؤقت القلم داخل النطاق ثم إيقاف الجهاز:
```c timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); ```
لا تضمن الدالة `timer_delete_sync()` سوى أن المؤقت يكون في حالة خمول (idle) عند تلك اللحظة. تستمر دالة `uclogic_raw_event_pen()` في إرسال تقارير القلم حتى تقوم `hid_hw_stop()` بإيقاف النقل البروتوكولي بعد عدة أسطر، وكل تقرير يحتوي على قيمة `pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE` يعيد ضبط المؤقت:
```c mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); ```
يؤدي وصول تقرير بين استدعاء `timer_delete_sync()` وانهيار النقل في `hid_hw_stop()` إلى إعادة تفعيل `inrange_timer` بعد إلغائه. ثم تعود دالة `uclogic_remove()` وتتم إزالة (free) بيانات الجهاز (`devm drvdata`)، بينما قامت `hid_hw_stop()` بالفعل بتحرير البيانات الخاصة بجهاز الإدخال التي يشير إليها `drvdata->pen_input`. وبالتالي، عندما يتم تشغيل المؤقت بعد حوالي 100 مللي ثانية، تقوم دالة `uclogic_inrange_timeout()` بالإشارة إلى ذاكرة تم تحريرها -- وهو خطأ استخدام الذاكرة بعد تحريرها (use-after-free) في سياق softirq للمؤقت.
لا يُعد تبديل ترتيب الاستدعاءين حلاً: فإيقاف الجهاز أولاً يؤدي إلى إزالة بيانات `drvdata->pen_input` عبر دالة `hidinput_disconnect()` بينما قد يكون المؤقت لا يزال معلقاً، مما يعني أن مؤقّتاً تم تفعيله مسبقاً قبل الإزالة سيعمل على جهاز الإدخال المحذوف في الفترة الزمنية التي تسبق تشغيل `timer_delete_sync()`.
استخدم بدلاً من ذلك `timer_shutdown_sync()` قبل استدعاء `hid_hw_stop()`. تقوم هذه الدالة بإلغاء المؤقت، وانتظار انتهاء أي استدعاء قيد التنفيذ بينما تكون بيانات `pen_input` صالحة بعد، وتمنع أي إعادة تفعيل أخرى -- حيث يتم تجاهل أي استدعاء لاحق لـ `mod_timer()` ناتج عن تقرير في مرحلة النقل بصمت -- وبالتالي يكون المؤقت ميتاً بشكل مثبت قبل أن تقوم `hid_hw_stop()` بتحرير مدخلات الإدخال. هذا هو الترتيب الذي توثقه نواة المؤقتات (timer core) لهذه الحالة الخاصة بإنهاء التشغيل "إعادة تفعيل المؤقت من مسار آخر".
If you want to get the best quality for vulnerability data then you always have to consider VulDB.