CVE-2026-99007: drm/fb-helper: defer setup when fbdev_probe() fails, not just on -EAGAIN

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

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

drmfbhelperinitialconfigandunlock() calls drmclientmodesetprobe() first, which already fills in each modeset->mode/numconnectors for every connected output, and only afterwards calls drmfbhelpersinglefbprobe() to create fbhelper->fb and wire it into those modesets via drmsetupcrtcsfb().

If drmfbhelpersinglefbprobe() fails with anything other than -EAGAIN (e.g. dev->driver->fbdevprobe() itself fails), the function bails out before drmsetupcrtcsfb() runs and before setting fbhelper->deferredsetup. The client is left with modesets that have a mode and connectors but modeset->fb == NULL, and nothing marks this fbhelper as needing a retry.

drmfbhelperrestorefbdevmodeunlocked() only skips committing when fbhelper->deferredsetup is set, so a later .restore() call (drmlastclose() on process exit, in this report) commits the stale modeset through drmclientmodesetcommit() -> drmclientmodesetcommitatomic() -> drmatomichelpersetconfig(), which hits WARNON(!set->fb).

Mark fbhelper->deferredsetup on any drmfbhelpersinglefbprobe() failure, not just -EAGAIN, so restore keeps skipping the commit until a later hotplug event successfully re-probes and re-populates modeset->fb. The real error code is still returned to the caller unchanged.