CVE-2026-31488

What it actually does

This is a Linux kernel use-after-free in the AMDGPU display driver’s Display Stream Compression (DSC) validation path. During an atomic modeset involving DisplayPort Multi-Stream Transport (DP-MST), DSC, and an unrelated display mode change, the driver can incorrectly clear the CRTC mode_changed state. That causes AMDGPU display stream lifetime tracking to become inconsistent: an old stream may not be released correctly, a new stream may not receive the expected reference, and the stream can later be freed while still reachable. Subsequent framebuffer removal or display teardown can then write to freed kernel memory in dc_stream_release(). Because the flaw occurs in kernel context, successful exploitation can potentially cause a kernel crash, denial of service, or, depending on allocator state and exploit reliability, local privilege escalation.

Why it matters to the business

Systems using AMD GPUs with affected Linux kernels may be vulnerable to local crashes or kernel-level compromise when display configurations are changed, especially in environments using external DisplayPort MST docks, multi-monitor setups, DSC, HDR, or dynamic laptop panel reconfiguration. The operational risk is highest for Linux workstations, developer laptops, VDI endpoints with GPU passthrough, kiosks, and graphics-heavy engineering systems where local users or desktop sessions can exercise display-management paths. The CVSS score indicates high potential impact, but EPSS is very low, there is no known exploited-in-the-wild status, and no public exploit maturity is reported, so remediation should be prioritized based on exposure of AMDGPU-enabled Linux endpoints rather than emergency internet-facing risk.

How an attack unfolds

An attacker needs local ability to interact with the graphics stack, typically through a logged-in desktop session or another path that can trigger Kernel Mode Setting operations. The attacker manipulates display state so that a DSC/MST configuration change occurs in the same atomic commit as an unrelated mode change, such as attaching or emulating DP-MST displays while changing laptop panel settings like HDR or mode properties. The vulnerable AMDGPU code pre-validates DSC and incorrectly restores the mode_changed flag, causing the atomic commit path to skip necessary stream lifecycle handling. Later, when a framebuffer is removed or a stream is disabled, the driver can release or modify an already-freed dc_stream object. A basic exploit may simply crash the kernel; a more advanced exploit would attempt to shape kernel heap memory around the freed object and turn the use-after-free into controlled memory corruption for privilege escalation. No named threat actors or active campaigns are currently associated with this vulnerability in the provided data.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream AMDGPU fix from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b or the equivalent vendor backport. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or hardware vendor and confirm that the drm/amd/display DSC validation patch is included. Prioritize endpoints and workstations with AMD GPUs, DP-MST docks, multi-monitor configurations, HDR-capable internal panels, or environments where untrusted local users can start graphical sessions. If immediate patching is not possible, reduce exposure by limiting local interactive access, disabling or avoiding DP-MST/docking workflows where feasible, disabling DSC/HDR features if supported by policy or configuration, and restricting untrusted users from accessing graphical/KMS-capable sessions. Mitigations are risk-reduction measures only; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel package is at or above the distribution’s fixed version and that the vendor changelog references the AMDGPU DSC validation fix, the upstream commit cc7c7121ae082b7b82891baa7280f1ff2608f22b, or wording equivalent to not skipping unrelated mode changes in DSC validation. Verify the affected systems load the patched amdgpu module after reboot, because replacing kernel packages without rebooting leaves the vulnerable code active. On representative AMDGPU systems, test display workflows involving DP-MST, docking/undocking, HDR toggling, and framebuffer/session teardown, and confirm there are no kernel logs indicating KASAN use-after-free, dc_stream_release faults, amdgpu display crashes, or GPU display manager errors. Where available, compare kernel source or distro patch metadata to ensure pre_validate_dsc() restores the prior mode_changed value instead of unconditionally clearing it.

Typical attack path

1. Gain local access to an affected Linux system using the AMDGPU display driver.
2. Ensure the system is using a display topology that can exercise DSC and/or DP-MST behavior, such as external DisplayPort MST monitors, docks, or dynamic panel reconfiguration.
3. Trigger a KMS atomic commit that combines DSC/MST configuration changes with an unrelated mode change on another CRTC or panel.
4. Cause the AMDGPU driver to incorrectly clear the mode_changed flag during DSC pre-validation.
5. Wait for or trigger framebuffer removal, stream disablement, display unplug, session logout, or another display teardown path.
6. Reach dc_stream_release() or related AMDGPU display cleanup logic with a stale stream reference.
7. Cause a kernel crash or attempt to exploit the freed kernel object for elevated privileges.

How to detect it

Review kernel logs, persistent journal entries, crash dumps, and endpoint telemetry from AMDGPU-enabled Linux systems for evidence of crashes or memory-safety reports during display configuration changes. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, apport/ABRT reports, kdump/vmcore artifacts, kernel oops reports, and EDR telemetry that captures kernel panics or module faults. Focus on events around monitor hotplug, docking or undocking, DP-MST topology changes, HDR enablement or disablement, display mode changes, framebuffer removal, graphical logout, compositor restart, or Xorg/Wayland session teardown. Look for KASAN use-after-free reports or kernel oops traces involving AMDGPU display stream cleanup functions such as dc_stream_release(), dc_state_destruct(), dc_state_release(), dm_atomic_destroy_state(), drm_atomic_state_default_clear(), atomic_remove_fb(), drm_mode_rmfb_work_fn(), or amdgpu_dm_atomic_commit_tail(). Absence of these artifacts does not prove non-exploitation, especially on production kernels without KASAN; however, repeated AMDGPU display crashes tied to local display manipulation should be investigated as suspicious on unpatched systems.

• BUG: KASAN: use-after-free in dc_stream_release
• dc_stream_release+0x25/0x90 [amdgpu]
• Workqueue: events drm_mode_rmfb_work_fn
• dm_atomic_destroy_state+0x3f/0x70 [amdgpu]
• dc_state_destruct+0x14d/0x5c0 [amdgpu]
• dc_state_release.part.0+0x4e/0x130 [amdgpu]
• drm_atomic_state_default_clear
• atomic_remove_fb
• amdgpu_dm_atomic_commit_tail
• pre_validate_dsc
• drm/amd/display
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• amdgpu

What your security team should do

• Inventory Linux endpoints, workstations, and virtual desktop images using AMD GPUs and the amdgpu kernel module.
• Prioritize kernel updates for systems with local multi-user access, developer workstations, shared lab machines, kiosks, or AMDGPU systems using DP-MST docks and multi-monitor setups.
• Apply the distribution or vendor kernel update containing upstream commit cc7c7121ae082b7b82891baa7280f1ff2608f22b, then reboot to activate the patched kernel.
• Temporarily limit untrusted local graphical access on affected systems that cannot be patched quickly.
• Monitor kernel logs for AMDGPU display use-after-free, KASAN, general protection fault, BUG, WARNING, or crash signatures involving dc_stream_release, dc_state_destruct, dm_atomic_destroy_state, drm_mode_rmfb_work_fn, or atomic_remove_fb.
• Treat unexpected kernel crashes during monitor hotplug, docking, undocking, HDR changes, display mode changes, or logout on AMDGPU systems as potentially relevant until patched.
• Do not rely on EPSS alone for prioritization: exploitation requires local access, but kernel memory corruption can have high host impact.