EUVD-2026-39341
GHSA-rg3c-j3j2-x6pc
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Malicious input comes from VBIOS firmware, so supplying it needs firmware-flash/root or physical device control (PR:H); local vector, no user interaction, high memory-corruption impact.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Clamp VBIOS HDMI retimer register count to array size
[Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe.
Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1().
(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)
AnalysisAI
Out-of-bounds heap write in the Linux kernel amdgpu DRM display driver (drm/amd/display) arises because the VBIOS integrated info tables (v1_11 and v2_1) expose unvalidated u8 HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C settings into fixed-size arrays (9 and 3 elements). A malformed VBIOS can set these counts up to 255, overrunning the destination arrays during driver probe on AMD GPU systems. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires that the system runs the AMD amdgpu DRM display driver and that the attacker controls the content of the VBIOS integrated info tables (v1_11 or v2_1) - specifically the HdmiRegNum or Hdmi6GRegNum register-count fields - which are consumed only during driver probe (typically at boot or GPU hotplug/reinitialization). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) reflects local access with high impact, but this understates a key limiting factor: the malicious input originates from the VBIOS firmware tables, which an unprivileged local user cannot normally alter. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who can flash the GPU VBIOS or present an attacker-controlled GPU/eGPU with a crafted integrated-info table sets HdmiRegNum or Hdmi6GRegNum to a large value (up to 255). When the amdgpu driver probes the device, the copy loop writes past the fixed 9- or 3-element retimer setting arrays, corrupting adjacent kernel heap memory and enabling denial of service or potential privilege escalation. … |
| Remediation | Vendor-released patch: upgrade to a fixed stable kernel - 5.15.210, 6.1.176, 6.6.143, 6.12.94, 7.0.13, 6.18.36, or 7.1 (or later within each series) - which clamp HdmiRegNum/Hdmi6GRegNum with min_t() before the copy loops; the corresponding commits are at https://git.kernel.org/stable/c/029571d51140650783be4fb98fe7cb4754752086 and the sibling stable hashes. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Inventory systems with AMD GPUs and assess VBIOS exposure; within 7 days: obtain and test vendor patches for the Linux kernel amdgpu DRM driver in non-production; within 30 days: deploy patches to all affected production systems.
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, and 12.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable memory corruption vulnerability exists in AMD atidxx64.dll 26.20.15019.19000 graphics driver. Rated criti
plays_service.exe in the plays.tv service before 1.27.7.0, as distributed in AMD driver-installation packages and Gaming
A flaw was found in the KVM's AMD code for supporting SVM nested virtualization. Rated high severity (CVSS 8.8), this vu
AMD ATI atillk64.sys 5.11.9.0 allows low-privileged users to interact directly with physical memory by calling one of se
An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13001.29010. Rated high
AMD fglrx-driver before 15.9 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),
AMD fglrx-driver before 15.7 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),
A vulnerability, which was classified as critical, has been found in TechPowerUp Ryzen DRAM Calculator 1.2.0.5.sys. Rate
Same weakness CWE-787 – Out-of-bounds Write
View allSame technique Memory Corruption
View allShare
External POC / Exploit Code
Leaving vuln.today