Cloudanix VulnDB

CVE-2026-99007

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux graphics handling bug could cause unexpected system warnings or display problems when programs using the screen shut down.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Failure to mark fb_helper as needing deferred_setup on any drm_fb_helper_single_fb_probe() error except -EAGAIN leaves mode_sets with valid mode/num_connectors but NULL fb; subsequent restore paths call drm_client_modeset_commit_atomic which hits WARN_ON(!set->fb).

Why it matters to the business

Graphics subsystem instability or kernel warnings on process exit or hotplug events on affected Linux systems, potentially requiring reboots or reducing reliability of display hardware.

How an attack unfolds

An attacker with local access triggers a non-EAGAIN fbdev_probe failure during initial DRM client setup, then forces a .restore() call (such as drm_lastclose on process exit) to commit the incomplete mode_set and surface the warning.

How to fix it

Apply the upstream kernel patch that sets deferred_setup on any drm_fb_helper_single_fb_probe failure; rebuild and reboot with the corrected drm/fb-helper code.

How to confirm the fix worked

After patching, confirm absence of the WARN_ON(!set->fb) message in kernel logs during graphics client close or hotplug; verify fb_helper->deferred_setup is set on probe errors via code inspection or debug prints.

Typical attack path

  1. Trigger graphics device initialization that causes drm_fb_helper_single_fb_probe to return a non-EAGAIN error
  2. Allow process exit or hotplug event to invoke __drm_fb_helper_restore_fbdev_mode_unlocked
  3. Observe WARN_ON in __drm_atomic_helper_set_config due to missing fb pointer

How to detect it

Search kernel ring buffer and dmesg for drm_client_modeset_commit_atomic or __drm_atomic_helper_set_config warnings referencing missing fb pointers; correlate with recent process exits involving DRM clients.

What your security team should do

  • Prioritize kernel updates containing this drm/fb-helper fix on all affected Linux distributions
  • Monitor kernel logs for drm and fbdev warnings as an early indicator of exposure
  • Test graphics workloads with simulated probe failures in staging environments before broad deployment

The record

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.

Affected packages

Ecosystem Package Introduced Fixed