CVE-2026-31488
Received Received - Intake
Use-After-Free in Linux amdgpu DRM Due to DSC Mode Change Handling

Publication date: 2026-04-22

Last updated on: 2026-04-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Do not skip unrelated mode changes in DSC validation Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-22
Last Modified
2026-04-28
Generated
2026-05-07
AI Q&A
2026-04-22
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.18
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.21 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.11 (exc)
linux linux_kernel From 5.18.1 (inc) to 6.12.80 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's AMD GPU display driver (amdgpu). It involves incorrect handling of mode changes during Display Stream Compression (DSC) validation. Specifically, when multiple changes occur in the same Kernel Mode Setting (KMS) commitβ€”some related to DSC and others unrelatedβ€”the driver incorrectly resets a flag (mode_changed) that tracks whether a display mode has changed. This causes the driver to skip processing some mode changes, leading to a memory leak and a use-after-free error when the display stream is later disabled.

The issue arises because the driver drops the mode_changed flag incorrectly for integrated panels when external DisplayPort Multi-Stream Transport (DP-MST) screens are plugged in, even if the DSC configuration did not change. This results in old display streams not being released and new streams not being properly referenced, causing kernel memory errors.


How can this vulnerability impact me? :

This vulnerability can lead to memory leaks and use-after-free errors in the Linux kernel's AMD GPU driver. Such memory corruption issues can cause system instability, crashes, or unexpected behavior when managing display outputs, especially when connecting or disconnecting external monitors.

In practical terms, users of affected systems might experience graphical glitches, system crashes, or kernel panics when changing display configurations involving DSC and DP-MST. Additionally, memory corruption vulnerabilities can potentially be exploited to escalate privileges or execute arbitrary code, although no specific exploit details are provided.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved in the Linux kernel by a patch that correctly handles the mode_changed flag during DSC validation in the amdgpu driver.

To mitigate this vulnerability, you should update your Linux kernel to a version that includes the fix (commit cc7c7121ae082b7b82891baa7280f1ff2608f22b or later).

This update prevents memory leaks and use-after-free errors related to DSC configuration changes in amdgpu.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a use-after-free bug in the amdgpu driver, which can cause kernel errors related to memory management in the DRM AMD display subsystem.

Detection would typically involve monitoring kernel logs for specific error messages indicating the issue, such as KASAN (Kernel Address Sanitizer) reports of use-after-free in dc_stream_release within the amdgpu module.

  • Check kernel logs for error messages using: dmesg | grep -i amdgpu
  • Look specifically for KASAN use-after-free reports: dmesg | grep -i kasan
  • Monitor for BUG messages related to dc_stream_release or drm_mode_rmfb_work_fn in kernel logs.

Since this is a kernel-level issue related to the amdgpu driver, no specific network commands are applicable for detection.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not include any details about the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart