CVE-2026-99007

In the Linux kernel, the following vulnerability has been resolved:

drm/fb-helper: defer setup when fbdev probe() fails, not just on -EAGAIN

drm fb helper initial config and unlock() calls drm client modeset probe() first, which already fills in each mode set->mode/num connectors for every connected output, and only afterwards calls drm fb helper single fb probe() to create fb helper->fb and wire it into those mode sets via drm setup crtcs fb().

If drm fb helper single fb probe() fails with anything other than -EAGAIN (e.g. dev->driver->fbdev probe() itself fails), the function bails out before drm setup crtcs fb() runs and before setting fb helper->deferred setup. The client is left with mode sets that have a mode and connectors but mode set->fb == NULL, and nothing marks this fb helper as needing a retry.

drm fb helper restore fbdev mode unlocked() only skips committing when fb helper->deferred setup is set, so a later .restore() call (drm lastclose() on process exit, in this report) commits the stale mode set through drm client modeset commit() -> drm client modeset commit atomic() -> drm atomic helper set config(), which hits WARN ON(!set->fb).

Mark fb helper->deferred setup on any drm fb helper single fb probe() failure, not just -EAGAIN, so restore keeps skipping the commit until a later hotplug event successfully re-probes and re-populates mode set->fb. The real error code is still returned to the caller unchanged.