drm/amdgpu: zero-initialize GART table on allocation (CVE-2026-53374) | HOL Guard CVE

Unknown severity · Source severity not reportedCVE-2026-53374

drm/amdgpu: zero-initialize GART table on allocation

Answer in brief

CVE-2026-53374 records a Unknown severity vulnerability in drm/amdgpu: zero-initialize GART table on allocation. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Jul 19, 2026Updated Aug 5, 2026Source checked Sep 20, 2026First seen by HOL Aug 5, 2026Material review Aug 5, 2026

Upstream Advisory

Key facts

Risk: Unknown severitySource severity not reported
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=d38ceaf99ed015f2a0b9af3499791bd3a3daae21 <40df11255d71b02e20e70579f1b12b687e396e26 \|\| >=d38ceaf99ed015f2a0b9af3499791bd3a3daae21 <91fbb5e635c8fb1b49e15c19da06480089ef719f \|\| >=d38ceaf99ed015f2a0b9af3499791bd3a3daae21 <8ae8b9e74bab94aab1d79f1688129bcc61c8b29a \|\| >=d38ceaf99ed015f2a0b9af3499791bd3a3daae21 <b17175d0a375b3ed5e81597dac4983fdb46e478d \|\| >=d38ceaf99ed015f2a0b9af3499791bd3a3daae21 <791941be5da125d9a1b228582bfdc300c05d05b3 \|\| >=d38ceaf99ed015f2a0b9af3499791bd3a3daae21 <e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741	40df11255d71b02e20e70579f1b12b687e396e26, 91fbb5e635c8fb1b49e15c19da06480089ef719f, 8ae8b9e74bab94aab1d79f1688129bcc61c8b29a, b17175d0a375b3ed5e81597dac4983fdb46e478d, 791941be5da125d9a1b228582bfdc300c05d05b3, e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741
Linux/Linuxgeneric	4.2	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to 40df11255d71b02e20e70579f1b12b687e396e26 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Aug 5, 2026

Sources and claim methodology

Upstream source 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)

Quoted source text, attributed separately from HOL analysis.