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.
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.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| 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 |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
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.
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.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| 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 |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.