CVE-2026-98523: drm/client: fix restore of partially initialized client
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/drmatomic.c:2031 at drmatomichelpersetconfig+0x18e/0x1b0 [drm]
Call Trace: drmclientmodesetcommitatomic+0x16b/0x220 [drm] drmclientmodesetcommitlocked+0x56/0x160 [drm] drmclientmodesetcommit+0x21/0x40 [drm] drmfbhelperrestorefbdevmodeunlocked.part.0+0x7b/0x80 drmfbdevclientrestore+0xe/0x20 [drmclientlib] drmclientdevrestore+0x9f/0xc0 [drm] drmrelease+0xc5/0xe0 [drm]
The warning is followed by a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: drmfbhelperrestorefbdevmodeunlocked.part.0+0x41/0x80 [drmkmshelper]
Call Trace: drmfbdevclientrestore+0xe/0x20 [drmclientlib] drmclientdevrestore+0x9f/0xc0 [drm] drmrelease+0xc5/0xe0 [drm] fput+0xdc/0x2b0 x64sysclose+0x39/0x80 dosyscall64+0x8d/0x460 entrySYSCALL64afterhwframe+0x76/0x7e
drmclientregister() 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 drmfbhelperinitialconfig() causes the partially initialized fbdev helper to be cleaned up. drmfbhelperfini() releases fbhelper->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, drmrelease() can invoke the restore callbacks of registered DRM clients:
drmrelease() drmclientdevrestore() drmfbdevclientrestore() drmfbhelperrestorefbdevmodeunlocked()
drmfbdevclientrestore() 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.
drmfbdevclientunregister() already uses fbhelper->info to distinguish a fully probed framebuffer device from a partially initialized client.
Use the same condition in drmfbdevclientrestore() and skip restore if no framebuffer device has been successfully initialized.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What condition triggers the crash?
The failure occurs when a DRM client is added to the device client list before its initial hotplug callback completes, leaving the client partially initialized. Closing the associated DRM file descriptor can then invoke client restore handling and dereference a NULL pointer.
Who is most likely to be exposed?
Systems using the Linux kernel DRM stack are relevant when a DRM client can be left partially initialized during its initial hotplug callback. The reported crash path is reached while closing a DRM file descriptor.
How can I tell whether this has already occurred?
Look for a kernel warning from __drm_atomic_helper_set_config followed by a NULL pointer dereference in __drm_fb_helper_restore_fbdev_mode_unlocked. The stack trace includes drm_fbdev_client_restore, drm_client_dev_restore, drm_release, and the close system-call path.
Are fixed versions identified in the available data?
No fixed kernel version numbers are provided. The available data includes stable-kernel commit references for the resolution.