GHSA-G687-J9P7-P4RX

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31
VLAI
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-99007"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:23Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/fb-helper: defer setup when fbdev_probe() fails, not just on -EAGAIN\n\n__drm_fb_helper_initial_config_and_unlock() calls\ndrm_client_modeset_probe() first, which already fills in each\nmode_set-\u003emode/num_connectors for every connected output, and only\nafterwards calls drm_fb_helper_single_fb_probe() to create\nfb_helper-\u003efb and wire it into those mode_sets via\ndrm_setup_crtcs_fb().\n\nIf drm_fb_helper_single_fb_probe() fails with anything other than\n-EAGAIN (e.g. dev-\u003edriver-\u003efbdev_probe() itself fails), the function\nbails out before drm_setup_crtcs_fb() runs and before setting\nfb_helper-\u003edeferred_setup. The client is left with mode_sets that\nhave a mode and connectors but mode_set-\u003efb == NULL, and nothing\nmarks this fb_helper as needing a retry.\n\n__drm_fb_helper_restore_fbdev_mode_unlocked() only skips committing\nwhen fb_helper-\u003edeferred_setup is set, so a later .restore() call\n(drm_lastclose() on process exit, in this report) commits the stale\nmode_set through drm_client_modeset_commit() -\u003e\ndrm_client_modeset_commit_atomic() -\u003e __drm_atomic_helper_set_config(),\nwhich hits WARN_ON(!set-\u003efb).\n\nMark fb_helper-\u003edeferred_setup on any drm_fb_helper_single_fb_probe()\nfailure, not just -EAGAIN, so restore keeps skipping the commit until\na later hotplug event successfully re-probes and re-populates\nmode_set-\u003efb. The real error code is still returned to the caller\nunchanged.",
  "id": "GHSA-g687-j9p7-p4rx",
  "modified": "2026-10-23T15:31:34Z",
  "published": "2026-10-23T15:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99007"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3b303696f61461b3569019d7fcac6a646652b2b4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4a2006c675758f0c765b36fec6b49d17e89159cf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4e7b508c7c60dec7a86b7eb2a1b7e6d174afa457"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/755c94d178b7e972bb766199d34e4ba4f63a89eb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d510ed273854177f0a3ed330145858b2fe667f81"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.