CVE-2026-98749 in Linux
الملخص
بحسب VulDB • 19/10/2026
في نواة لينكس، تم حل الثغرة التالية:
tty: serial: max3100: إيقاف المؤقت قبل تحرير المنفذ (port)
تقوم دالة `max3100_shutdown()` بإيقاف مؤقت الاستطلاع (polling timer)، لكنها تعود مبكرًا أثناء تعليق النظام (system suspend). إذا تمت إزالة ارتباط الجهاز SPI (unbound) قبل استئناف التشغيل، فإن النواة التسلسلية لا تستدعي `max3100_shutdown()` مرة أخرى، مما يؤدي إلى قيام دالة `max3100_remove()` بتحرير المنفذ بينما يظل المؤقت نشطًا. قد تؤدي دالة `max3100_timeout()` بعد ذلك إلى الوصول إلى المنفذ المحرّر وإعادة ضبط المؤقت.
أضف عملية الإغلاق النهائية للمؤقت في `max3100_remove()` واستخدم `timer_shutdown_sync()` لمنع استدعاء متزامن (racing callback) من إعادة ضبطه. قم أيضًا بتحرير مقاطعة الجهاز (IRQ) وتدمير قائمة العمل (workqueue) هناك قبل تحرير المنفذ. احتفظ بـ `timer_delete_sync()` في `max3100_shutdown()` بحيث يمكن لفتح (`open()`) لاحقًا إعادة ضبط المؤقت.
تم إنشاء قائمة العمل قبل استدعاء `request_irq()`، وتم تدميرها عند فشل `request_irq()` وعند الإغلاق الطبيعي. وجودها أثناء عملية الإزالة يحدد بذلك أن مقاطعة الجهاز (IRQ) لا تزال مسجلة عندما يتجاوز تعليق النظام عملية الإغلاق.
قم بتحرير مقاطعة الجهاز (IRQ) قبل تدمير قائمة العمل، سواء في `max3100_shutdown()` أو `max3100_remove()**، وقم بإلغاء الأعمال المعلقة بينهما. تنتظر دالة `free_irq()` انتهاء معالج المقاطعة الجاري ولا يمكن لمعالج جديد أن يبدأ بعد ذلك، لذا لا يستطيع معالج متزامن (racing handler) جدولة عمل على قائمة عمل يتم تدميرها؛ ففحص `force_end_work` في `max3100_dowork()` يضيّق هذه الفترة الزمنية فقط، حيث قد يعمل معالج مُؤجل بين الفحص واستدعاء `queue_work()` بعد أن يؤدي الإغلاق إلى مسح مؤشر قائمة العمل. كما يمنع إلغاء الأعمال دالة `destroy_workqueue()` من الانتظار على عنصر عمل مجدول في حال تشغيل عملية الإزالة (`remove()`) بينما كانت قائمة العمل القابلة للتجميد (freezable workqueue) لا تزال مجمدة، مثلًا أثناء إزالة الجهاز خلال نافذة الاستئناف، قبل إذابة قوائم العمل.
تم العثور على هذه المشكلة باستخدام أداة تحليل ثابتة داخلية.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.