CVE-2026-99007 in Linux
Сводка
по VulDB • 23.10.2026
В ядре Linux была устранена следующая уязвимость:
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 и подключения его к этим режимным наборам через 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-ами, которые содержат режимы и коннекторы, но у которых mode_set->fb == NULL, при этом ничего не помечает этот fb_helper как требующий повторной попытки.
Функция __drm_fb_helper_restore_fbdev_mode_unlocked() пропускает коммит только в том случае, если установлен флаг 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. Реальный код ошибки по-прежнему возвращается вызывающей стороне без изменений.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.