CVE-2026-98859 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم حل الثغرة التالية:
HID: multitouch: منع إعادة تشغيل مؤقت الإزالة (release timer) عند عملية الإزالة
تقوم الدالة `mt_remove()` بهدأة مؤقت الأصابع اللاصقة (sticky-finger timer) قبل إيقاف العتاد:
timer_delete_sync(&td->release_timer);
sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group); hid_hw_stop(hdev);
تنتظر الدالة `timer_delete_sync()` انتهاء استدعاء تشغيلي قيد التنفيذ وتزيل المؤقت من قائمة الانتظار، لكنها لا تمنع إعادة تهيئة (arming) المؤقت. في تلك المرحلة، ما زالت طبقة النقل تقدم التقارير (reports)، ومسار التقرير يعيد تهيئته:
if (app->quirks & MT_QUIRK_STICKY_FINGERS) {
if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100));
وبالتالي، فإن التقرير الذي يصل بعد عودة `timer_delete_sync()` يترك المؤقت في قائمة الانتظار. تم تخصيص `td` باستخدام `devm_kzalloc()` مقابل `hdev->dev`، لذا يتم تحريرها عندما يُفك ارتباط السائق (driver)، وذلك بعد أن تعود الدالة `mt_remove()`. وعندما يشتعل المؤقت لاحقاً، فإن `mt_expired_timeout()` يشير إلى الذاكرة المحررة الخاصة بـ `td`:
struct mt_device *td = timer_container_of(td, t, release_timer); struct hid_device *hdev = td->hdev;
if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
فقط نقل عملية التفكيك بعد استدعاء `hid_hw_stop()` لا يحل هذه المشكلة بمفردها، لأن `mt_expired_timeout()` تستدعي `mt_release_contacts()`، التي تتنقل عبر `hdev->inputs`؛ ولا يزال يجب تهدئة المؤقت قبل أن تقوم `hid_hw_stop()` بتفكيك أجهزة الإدخال.
استخدم بدلاً من ذلك `timer_shutdown_sync()`، والتي تجعل أي استدعاء لاحق لـ `mod_timer()` بلا تأثير (no-op)، وبالتالي لا يتعين التنازل عن أحد قيدي الترتيب مقابل الآخر. هذا هو نمط التفكيك النهائي الذي أُدخلت الدالة من أجله، وتستخدمه واجهة hid-wiimote بالفعل لنفس السبب.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.