Linux Kernel up to 6.12.79/6.18.20/6.19.10 pre_validate_dsc use after free

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 7.7 | $5k-$25k | 0.00 |
Summary
A vulnerability was found in Linux Kernel up to 6.12.79/6.18.20/6.19.10 and classified as critical. This affects the function pre_validate_dsc. The manipulation results in use after free.
This vulnerability is identified as CVE-2026-31488. There is not any exploit available.
It is suggested to upgrade the affected component.
Details
A vulnerability classified as critical has been found in Linux Kernel up to 6.12.79/6.18.20/6.19.10. Affected is the function pre_validate_dsc. The manipulation with an unknown input leads to a use after free vulnerability. CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:
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)
The advisory is available at git.kernel.org. This vulnerability is traded as CVE-2026-31488 since 03/09/2026. The exploitability is told to be easy. Technical details are known, but there is no available exploit. The structure of the vulnerability defines a possible price range of USD $5k-$25k at the moment (estimation calculated on 07/25/2026).
The vulnerability scanner Nessus provides a plugin with the ID 321812 (RHEL 8 : kernel-rt (RHSA-2026:27354)), which helps to determine the existence of the flaw in a target environment.
Upgrading to version 6.12.80, 6.18.21 or 6.19.11 eliminates this vulnerability. Applying the patch 10862e344b4d6434642a48c87d765813fc0b0ba7/8a5edc97fd9c6415ff2eff872748439a97e3c3d8/111208b5b7ebcdadb3f922cc52d8425f0fa91b33/aed3d041ab061ec8a64f50a3edda0f4db7280025 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.
The vulnerability is also documented in the databases at Tenable (321812) and CERT Bund (WID-SEC-2026-1252). If you want to get best quality of vulnerability data, you may have to visit VulDB.
Affected
- Google Container-Optimized OS
- Debian Linux
- Amazon Linux 2
- Red Hat Enterprise Linux
- Ubuntu Linux
- SUSE Linux
- Oracle Linux
- SUSE openSUSE
- RESF Rocky Linux
- Open Source Linux Kernel
- Siemens SIMATIC S7
- Proxmox Virtual Environment
Product
Type
Vendor
Name
Version
- 6.12.0
- 6.12.1
- 6.12.2
- 6.12.3
- 6.12.4
- 6.12.5
- 6.12.6
- 6.12.7
- 6.12.8
- 6.12.9
- 6.12.10
- 6.12.11
- 6.12.12
- 6.12.13
- 6.12.14
- 6.12.15
- 6.12.16
- 6.12.17
- 6.12.18
- 6.12.19
- 6.12.20
- 6.12.21
- 6.12.22
- 6.12.23
- 6.12.24
- 6.12.25
- 6.12.26
- 6.12.27
- 6.12.28
- 6.12.29
- 6.12.30
- 6.12.31
- 6.12.32
- 6.12.33
- 6.12.34
- 6.12.35
- 6.12.36
- 6.12.37
- 6.12.38
- 6.12.39
- 6.12.40
- 6.12.41
- 6.12.42
- 6.12.43
- 6.12.44
- 6.12.45
- 6.12.46
- 6.12.47
- 6.12.48
- 6.12.49
- 6.12.50
- 6.12.51
- 6.12.52
- 6.12.53
- 6.12.54
- 6.12.55
- 6.12.56
- 6.12.57
- 6.12.58
- 6.12.59
- 6.12.60
- 6.12.61
- 6.12.62
- 6.12.63
- 6.12.64
- 6.12.65
- 6.12.66
- 6.12.67
- 6.12.68
- 6.12.69
- 6.12.70
- 6.12.71
- 6.12.72
- 6.12.73
- 6.12.74
- 6.12.75
- 6.12.76
- 6.12.77
- 6.12.78
- 6.12.79
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.19.0
- 6.19.1
- 6.19.2
- 6.19.3
- 6.19.4
- 6.19.5
- 6.19.6
- 6.19.7
- 6.19.8
- 6.19.9
- 6.19.10
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 7.9VulDB Meta Temp Score: 7.7
VulDB Base Score: 8.0
VulDB Temp Score: 7.6
VulDB Vector: 🔒
VulDB Reliability: 🔍
CNA Base Score: 7.8
CNA Vector (Linux): 🔒
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Use after freeCWE: CWE-416 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒
Physical: Partially
Local: Yes
Remote: Partially
Availability: 🔒
Status: Not defined
EPSS Score: 🔒
EPSS Percentile: 🔒
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Nessus ID: 321812
Nessus Name: RHEL 8 : kernel-rt (RHSA-2026:27354)
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.12.80/6.18.21/6.19.11
Patch: 10862e344b4d6434642a48c87d765813fc0b0ba7/8a5edc97fd9c6415ff2eff872748439a97e3c3d8/111208b5b7ebcdadb3f922cc52d8425f0fa91b33/aed3d041ab061ec8a64f50a3edda0f4db7280025
Timeline
03/09/2026 CVE reserved04/22/2026 Advisory disclosed
04/22/2026 VulDB entry created
07/25/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-31488 (🔒)
GCVE (CVE): GCVE-0-2026-31488
GCVE (VulDB): GCVE-100-358866
CERT Bund: WID-SEC-2026-1252 - Linux Kernel: Mehrere Schwachstellen
Entry
Created: 04/22/2026 16:59Updated: 07/25/2026 20:24
Changes: 04/22/2026 16:59 (58), 05/17/2026 23:25 (12), 06/18/2026 02:23 (7), 06/21/2026 12:45 (2), 07/25/2026 20:24 (3)
Complete: 🔍
Cache ID: 216::103
If you want to get best quality of vulnerability data, you may have to visit VulDB.
No comments yet. Languages: en.
Please log in to comment.