CVE-2026-98841 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة Linux، تم حل الثغرة التالية:
virt: vmgenid: تعيين قيمة driver_data قبل تسجيل معالجات الإشعارات (notification handlers)
تقوم كلتا مسارتي الاستكشاف (probe paths) بتسجيل معالج الإشعارات الخاص بها قبل تعيين `driver_data`، والذي يقوم المعالج بإرجاعه (dereferencing).
في مسار devicetree، يمكن أن ينطلق IRQ للإشعار بمجرد قيام `devm_request_irq()` بتسجيل المعالج: فقد يكون المقطع الكهربائي (interrupt) معلقاً بالفعل عند وقت الاستكشاف، على سبيل المثال عندما يقوم VMM بحقن إشعار تغيير الجيل أثناء استعادة ضيف من لقطة شاشة تم أخذها قبل أن يستكشف السائق. كما يُطلب IRQ باستخدام `IRQF_SHARED`، لذا يمكن لجهاز آخر يشارك نفس الخط تشغيل المعالج في وقت مبكر جداً. ثم يتصل المعالج بـ `vmgenid_notify()`، والذي يقوم بإرجاع قيمة `driver_data` التي لا تزال NULL مما يؤدي إلى حدوث panic:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none) Hardware name: linux,dummy-virt (DT) pc : vmgenid_notify.isra.0+0x24/0x8c lr : vmgenid_of_irq_handler+0x14/0x34 Call trace: vmgenid_notify.isra.0+0x24/0x8c (P) vmgenid_of_irq_handler+0x14/0x34 __handle_irq_event_percpu+0x44/0x1bc handle_irq_event+0x4c/0xb4 handle_fasteoi_irq+0xf8/0x1f8
يحتوي مسار ACPI على نفس مشكلة الترتيب: يتم تثبيت المعالج باستخدام `acpi_install_notify_handler()` قبل تعيين `driver_data`. تُوزع إشعارات ACPI بشكل غير متزامن من خلال workqueue، لذا فإن النافذة الضيقة لا تزال تسمح بوصول إشعار بين الدالتين مما يؤدي إلى حدوث إرجاع NULL (NULL dereference) نفسه.
قم بتعيين قيمة `driver_data` قبل تسجيل المعالجات. تكون الحالة مُهيأة بالكامل في تلك النقطة، وبالتالي يكون تشغيل المعالجات آمناً. إذا فشل التسجيل، فإن مسار خطأ الاستكشاف لا يترك مؤشراً معلقاً خلفه: حيث يقوم نواة الجهاز (device core) بمسح قيمة `driver_data` في دالة `device_unbind_cleanup()`.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.