CVE-2026-99007 in Linux
Summary
by MITRE • 10/23/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability resides within the Linux kernel's Direct Rendering Manager framebuffer helper subsystem, specifically affecting the initialization logic for fbdev emulation layers. This issue manifests when the function __drm_fb_helper_initial_config_and_unlock() encounters a failure during the creation of the framebuffer object via drm_fb_helper_single_fb_probe(). The core technical flaw is an incomplete state management mechanism where the system fails to properly mark the frame buffer helper as requiring deferred setup upon any probe failure, rather than limiting this behavior exclusively to -EAGAIN error codes. This oversight leads to inconsistent internal states that can trigger kernel warnings and potential instability during subsequent operations such as device restoration or process termination.
The operational sequence begins with __drm_fb_helper_initial_config_and_unlock() invoking drm_client_modeset_probe(), which successfully populates mode_set structures with connector information and display modes for all connected outputs. Subsequently, the system attempts to create a framebuffer object by calling drm_fb_helper_single_fb_probe(). If this call fails due to reasons other than -EAGAIN, such as a failure in the driver-specific fbdev_probe() function, the execution path exits prematurely before executing drm_setup_crtcs_fb(). This critical step is responsible for linking the newly created framebuffer to the previously populated mode sets. Consequently, the resulting state consists of mode_set structures that contain valid modes and connectors but lack an associated framebuffer object, leaving mode_set->fb as NULL.
This incomplete initialization creates a dangerous condition because subsequent operations do not account for this partial setup. Specifically, when __drm_fb_helper_restore_fbdev_mode_unlocked() is invoked during events like drm_lastclose(), which occurs upon process exit or device close, it checks the fb_helper->deferred_setup flag to determine whether to skip committing changes. Since the deferred setup flag was never set due to the early bail-out on non-EAGAIN errors, the restore function proceeds to commit these stale mode sets through the atomic helper chain: drm_client_modeset_commit() leading to __drm_atomic_helper_set_config(). This final step encounters a NULL framebuffer pointer and triggers a WARN_ON(!set->fb) assertion. While this primarily results in kernel warnings that can clutter logs or indicate instability, it represents a significant deviation from expected robust error handling practices within the graphics stack.
From a security and stability perspective, this vulnerability aligns with CWE-253, which covers incorrect check before feature removal, as the system fails to correctly validate and manage the state of resources when initialization is incomplete. It also relates to CWE-841, Improper Enforcement of Behavioral Workflow, because the execution flow does not adhere to the required sequence of ensuring a valid framebuffer exists before allowing commit operations that depend on it. In terms of MITRE ATT&CK mapping, this behavior could be loosely associated with Tactic TA0005 Defense Evasion if an attacker were able to manipulate probe failures to cause denial-of-service through kernel warnings or instability, although the primary impact here is system stability rather than malicious exploitation. The lack of proper state transition handling means that transient hardware issues or driver bugs can lead to persistent incorrect states until a hotplug event forces a re-probe and corrects the configuration.
The remediation for this vulnerability involves modifying the error handling logic within __drm_fb_helper_initial_config_and_unlock() to set fb_helper->deferred_setup on any failure from drm_fb_helper_single_fb_probe(), not just when -EAGAIN is returned. This ensures that subsequent restore operations will correctly skip committing invalid configurations, thereby preventing the WARN_ON trigger and maintaining system stability until a successful re-probe can occur during hotplug events. The actual error code is still propagated to the caller unchanged, preserving accurate diagnostic information for developers while ensuring the internal state machine remains consistent. This fix reinforces the principle that partial initialization states must be explicitly marked as deferred to prevent invalid resource access in downstream functions.