CVE-2026-99007 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم حل الثغرة التالية:
drm/fb-helper: تأجيل الإعداد عند فشل fbdev_probe() وليس فقط في حالة -EAGAIN
تستدعي الدالة __drm_fb_helper_initial_config_and_unlock() دالة drm_client_modeset_probe() أولاً، والتي تقوم بالفعل بملء كل من mode_set->mode و num_connectors لكل مخرج متصل، وبعد ذلك تستدعي drm_fb_helper_single_fb_probe() لإنشاء fb_helper->fb وربطه مع مجموعات الإعدادات (mode_sets) عبر drm_setup_crtcs_fb().
إذا فشلت الدالة drm_fb_helper_single_fb_probe() بأي شيء آخر غير -EAGAIN (على سبيل المثال إذا فشل dev->driver->fbdev_probe() نفسه)، فإنها تنسحب قبل تشغيل drm_setup_crtcs_fb() وقبل تعيين fb_helper->deferred_setup. ينتج عن ذلك بقاء العميل مع مجموعات إعدادات تحتوي على وضع موصل وموصلات، لكن mode_set->fb == NULL، ولا يوجد ما يحدد أن هذا الـ fb_helper يحتاج إلى إعادة محاولة.
تقوم الدالة __drm_fb_helper_restore_fbdev_mode_unlocked() بتخطي الالتزام (commit) فقط عندما يكون fb_helper->deferred_setup مضبوطاً، لذا فإن استدعاء .restore() لاحقاً (مثل drm_lastclose() عند خروج العملية، كما ورد في هذا التقرير) يلتزم بـ mode_set القديم عبر drm_client_modeset_commit() -> drm_client_modeset_commit_atomic() -> __drm_atomic_helper_set_config()، مما يؤدي إلى حدوث تحذير WARN_ON(!set->fb).
قم بتعيين fb_helper->deferred_setup عند أي فشل لـ drm_fb_helper_single_fb_probe() وليس فقط في حالة -EAGAIN، بحيث يستمر restore في تخطي الالتزام حتى يعيد حدث الإضافة/الإزالة (hotplug) لاحقاً الفحص بنجاح ويعيد ملء mode_set->fb. يتم إرجاع رمز الخطأ الحقيقي إلى المتصل دون تغيير.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.