CVE-2026-99007 in Linux
摘要
由 VulDB • 2026-10-23
在 Linux 内核中，已修复以下漏洞：
drm/fb-helper: 当 fbdev_probe() 失败时推迟设置（setup），而不仅仅是在返回 -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() 将其连接到这些 mode_sets。
如果 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 被设置时才跳过提交（commit）。因此，后续的 .restore() 调用（在此报告中为进程退出时的 drm_lastclose()）会通过 drm_client_modeset_commit() -> drm_client_modeset_commit_atomic() -> __drm_atomic_helper_set_config() 提交过期的 mode_set，从而触发 WARN_ON(!set->fb)。
在任何 drm_fb_helper_single_fb_probe() 失败时都标记 fb_helper->deferred_setup，而不仅仅是在 -EAGAIN 情况下。这样 restore 会跳过提交操作，直到后续的热插拔事件成功重新探测并填充 mode_set->fb。实际错误码仍原样返回给调用者。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.