Cloudanix VulnDB

CVE-2026-98523

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the operating system's graphics code can make the whole computer crash when closing certain display-related programs under rare startup failure conditions.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Null pointer dereference in drm_fb_helper_restore_fbdev_mode_unlocked when a partially initialized fbdev DRM client (registered before hotplug callback failure) has its restore path invoked on drm_release, because fb_helper->info is NULL after drm_fb_helper_fini but the client remains on the device list.

Why it matters to the business

Kernel crashes and system instability on graphics-enabled Linux systems when userspace closes DRM file descriptors under specific initialization failure conditions, leading to denial of service and potential data loss for workloads relying on display or GPU devices.

How an attack unfolds

An attacker with local access triggers a hotplug callback failure during drm_client_register for the fbdev client so that a partially initialized client remains registered; later, closing the DRM file descriptor causes drm_release to call the unconditional restore path which dereferences uninitialized state and panics the kernel.

How to fix it

Update the Linux kernel to a version containing the fix that adds an fb_helper->info check inside drm_fbdev_client_restore before performing restore operations, matching the guard already present in drm_fbdev_client_unregister.

How to confirm the fix worked

Confirm the patched kernel version is running, then attempt to reproduce the partial initialization scenario (failed hotplug followed by DRM fd close) and verify absence of the NULL dereference oops in dmesg.

Typical attack path

  1. Obtain local unprivileged access on a Linux system using DRM/KMS graphics
  2. Force or wait for a hotplug callback failure during fbdev client initialization
  3. Close the DRM file descriptor to invoke drm_release and the faulty restore path
  4. Trigger kernel NULL pointer dereference and system crash

How to detect it

Inspect kernel logs (dmesg, /var/log/kern.log, journalctl) for oops traces containing __drm_atomic_helper_set_config, drm_fb_helper_restore_fbdev_mode_unlocked, drm_fbdev_client_restore, and drm_release around the time of unexpected reboots or crashes.

  • WARNING: drivers/gpu/drm/drm_atomic.c:2031 at __drm_atomic_helper_set_config
  • BUG: kernel NULL pointer dereference, address: 0000000000000008
  • RIP: __drm_fb_helper_restore_fbdev_mode_unlocked.part.0
  • Call Trace: drm_fbdev_client_restore+0xe/0x20

What your security team should do

  • Prioritize kernel updates on all systems exposing DRM graphics interfaces within the next patch cycle
  • Monitor vendor advisories for backported fixes in distribution kernels
  • Restrict unprivileged access to DRM devices via device permissions where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/client: fix restore of partially initialized client I got a null-ptr-deref report when closing a DRM file descriptor: WARNING: drivers/gpu/drm/drm_atomic.c:2031 at __drm_atomic_helper_set_config+0x18e/0x1b0 [drm] Call Trace: drm_client_modeset_commit_atomic+0x16b/0x220 [drm] drm_client_modeset_commit_locked+0x56/0x160 [drm] drm_client_modeset_commit+0x21/0x40 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x7b/0x80 drm_fbdev_client_restore+0xe/0x20 [drm_client_lib] drm_client_dev_restore+0x9f/0xc0 [drm] drm_release+0xc5/0xe0 [drm] The warning is followed by a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: __drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x41/0x80 [drm_kms_helper] Call Trace: drm_fbdev_client_restore+0xe/0x20 [drm_client_lib] drm_client_dev_restore+0x9f/0xc0 [drm] drm_release+0xc5/0xe0 [drm] __fput+0xdc/0x2b0 __x64_sys_close+0x39/0x80 do_syscall_64+0x8d/0x460 entry_SYSCALL_64_after_hwframe+0x76/0x7e drm_client_register() adds the DRM client to the device client list before invoking the initial hotplug callback. If the hotplug callback fails, the client remains registered. For the fbdev client, a failure during drm_fb_helper_initial_config() causes the partially initialized fbdev helper to be cleaned up. drm_fb_helper_fini() releases fb_helper->info and leaves it NULL. The fbdev client therefore remains registered even though there is no fully initialized framebuffer device. Later, when userspace closes the DRM file descriptor, drm_release() can invoke the restore callbacks of registered DRM clients: drm_release() drm_client_dev_restore() drm_fbdev_client_restore() drm_fb_helper_restore_fbdev_mode_unlocked() drm_fbdev_client_restore() currently restores the fbdev state unconditionally. For a partially initialized fbdev client this can submit an incomplete modeset state and subsequently access fbdev state which has not been initialized, resulting in the warning and NULL pointer dereference above. drm_fbdev_client_unregister() already uses fb_helper->info to distinguish a fully probed framebuffer device from a partially initialized client. Use the same condition in drm_fbdev_client_restore() and skip restore if no framebuffer device has been successfully initialized.

Affected packages

Ecosystem Package Introduced Fixed