CVE-2026-31488: drm/amd/display: Do not skip unrelated mode changes in DSC validation
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 modechanged 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 modechanged flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in prevalidatedsc().
At this point, however, dmupdatecrtcstate() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpudmcommitstreams() will never release the old stream, resulting in a memory leak. amdgpudmatomiccommittail() 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 dcstreamrelease+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977
Workqueue: events drmmodermfbworkfn Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 printaddressdescription.constprop.0+0x88/0x320 ? dcstreamrelease+0x25/0x90 [amdgpu] printreport+0xfc/0x1ff ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x225/0x4e0 ? dcstreamrelease+0x25/0x90 [amdgpu] kasanreport+0xe1/0x180 ? dcstreamrelease+0x25/0x90 [amdgpu] kasancheckrange+0x125/0x200 dcstreamrelease+0x25/0x90 [amdgpu] dcstatedestruct+0x14d/0x5c0 [amdgpu] dcstaterelease.part.0+0x4e/0x130 [amdgpu] dmatomicdestroystate+0x3f/0x70 [amdgpu] drmatomicstatedefaultclear+0x8ee/0xf30 ? drmmodeobjectput.part.0+0xb1/0x130 drmatomicstatefree+0x15c/0x2d0 atomicremovefb+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 modechanged flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the modechanged flag to this earlier value instead in prevalidatedsc().
(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
Affected Software
Event History
Frequently Asked Questions
Which systems and display scenarios are affected?
Systems using the Linux kernel amdgpu display driver are exposed when a KMS commit combines an MST/DSC configuration change with a separate, DSC-independent mode change. The described example is a laptop integrated panel whose configuration changes, such as HDR state, when external DisplayPort MST displays are connected.
What access is required to exploit this issue?
An attacker or local user needs the ability to trigger the relevant display configuration changes through the local graphics stack. The vector is local, requires low attack complexity and low privileges, and does not require user interaction.
What is the practical impact of a successful trigger?
The issue can leave an old display stream unreleased after the mode_changed flag is incorrectly cleared, causing a memory leak; subsequent commit processing can also operate without the expected stream reference. The provided severity vector rates confidentiality, integrity, and availability impact as high.
What can be done if patching is not immediately possible?
Apply a Linux kernel update containing the upstream stable fix referenced by the advisory. If updating cannot happen immediately, avoid combining external DisplayPort MST/DSC attachment or configuration changes with unrelated display mode changes in the same KMS commit where operationally feasible.