---
id: "CVE-2026-99007"
kind: "vulnerability"
aliases: ["CVE-2026-99007"]
title: "Linux DRM fbdev: failed probe leaves a stale mode that triggers a kernel warning"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["drm", "infrastructure", "linux-kernel"]
not_affected_if: []
published_at: "2026-10-23T13:17:23+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T04:55:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99007", "first_seen_at": "2026-10-23T21:57:33+00:00"}]
---

# Linux DRM fbdev: failed probe leaves a stale mode that triggers a kernel warning

When the framebuffer helper's probe fails with an error other than EAGAIN, the kernel keeps a half-built mode configuration and later commits it on process exit, hitting a WARN_ON. The fix defers setup on any probe failure so the stale configuration is skipped until a successful re-probe.

_Summary, check and fix written by a model from the sources; labelled as such._

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99007

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_