CVE-2026-53374

drm/amdgpu: zero-initialize GART table on allocation

Published Jul 19, 2026 CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: zero-initialize GART table on allocation

GART TLB is flushed after unmapping but not after mapping. Since
amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a
single PTE is written the TLB may speculatively load other uninitialized
entries from the same cacheline. Those garbage entries can appear valid,
and a subsequent write to another PTE in the same cacheline may cause the
GPU to use a stale garbage PTE from the TLB.

Fix this by calling memset_io() to zero-initialize the GART table with
gart_pte_flags immediately after allocation.

Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work
since SDMA needs GART to be initialized to work.

(cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-8574-1 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8593-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8574-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8595-1 Linux kernel (Oracle) vulnerabilities
Ubuntu USN Ubuntu USN USN-8596-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8595-2 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8603-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8606-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8607-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8608-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8609-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8574-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8595-3 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8618-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8619-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-8663-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8664-1 Linux kernel (NVIDIA BaseOS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8665-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-2 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-3 Linux kernel (Oracle) vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Type Values Removed Values Added
Weaknesses CWE-457
Type Values Removed Values Added
Metrics cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H'}

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: zero-initialize GART table on allocation GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)
Title drm/amdgpu: zero-initialize GART table on allocation
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 19, 2026, 8:07 PM
Reserved
Jun 9, 2026, 7:44 AM
Status
Modified
Published
Jul 19, 2026, 11:16 AM
Modified
Oct 19, 2026, 8:19 PM
Severity
Public date
Jul 19, 2026, 12:00 AM