Skip to main content
VulnerabilityPublished Updated

CVE-2026-31488: Linux kernel · drm/amd/display: Do not skip unrelated mode changes in DSC validation

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in da1d0ed31e9802fd99384f43cc63678a5a11cb41 : patch Linux kernel soon.

Data as of 26 Oct 2026, 12:55 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in da1d0ed31e9802fd99384f43cc63678a5a11cb41, aed3d041ab061ec8a64f50a3edda0f4db7280025, 111208b5b7ebcdadb3f922cc52d8425f0fa91b33 +3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 22 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 17ce8a6907f77b7ac97ddaa071d8a1f6e06ce85b, < da1d0ed31e9802fd99384f43cc63678a5a11cb41
Fixed in
  • da1d0ed31e9802fd99384f43cc63678a5a11cb41
LinuxLinuxAffected
  • ≥ 17ce8a6907f77b7ac97ddaa071d8a1f6e06ce85b, < aed3d041ab061ec8a64f50a3edda0f4db7280025
Fixed in
  • aed3d041ab061ec8a64f50a3edda0f4db7280025
LinuxLinuxAffected
  • ≥ 17ce8a6907f77b7ac97ddaa071d8a1f6e06ce85b, < 111208b5b7ebcdadb3f922cc52d8425f0fa91b33
Fixed in
  • 111208b5b7ebcdadb3f922cc52d8425f0fa91b33
LinuxLinuxAffected
  • ≥ 17ce8a6907f77b7ac97ddaa071d8a1f6e06ce85b, < 21159d8b335a6b9f44cbb506733013a902ae2da4
Fixed in
  • 21159d8b335a6b9f44cbb506733013a902ae2da4
LinuxLinuxAffected
  • ≥ 17ce8a6907f77b7ac97ddaa071d8a1f6e06ce85b, < 10862e344b4d6434642a48c87d765813fc0b0ba7
Fixed in
  • 10862e344b4d6434642a48c87d765813fc0b0ba7
LinuxLinuxAffected
  • ≥ 17ce8a6907f77b7ac97ddaa071d8a1f6e06ce85b, < 8a5edc97fd9c6415ff2eff872748439a97e3c3d8
Fixed in
  • 8a5edc97fd9c6415ff2eff872748439a97e3c3d8

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)

References

Community reviews

Loading reviews…