Skip to main content
VulnerabilityPublished Updated

CVE-2026-53374: Linux kernel · drm/amdgpu: zero-initialize GART table on allocation

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 8.8 High · fixed in e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741 : patch Linux kernel soon.

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
8.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741, b17175d0a375b3ed5e81597dac4983fdb46e478d, 791941be5da125d9a1b228582bfdc300c05d05b3 +3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ d38ceaf99ed015f2a0b9af3499791bd3a3daae21, < e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741
Fixed in
  • e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741
LinuxLinuxAffected
  • ≥ d38ceaf99ed015f2a0b9af3499791bd3a3daae21, < b17175d0a375b3ed5e81597dac4983fdb46e478d
Fixed in
  • b17175d0a375b3ed5e81597dac4983fdb46e478d
LinuxLinuxAffected
  • ≥ d38ceaf99ed015f2a0b9af3499791bd3a3daae21, < 791941be5da125d9a1b228582bfdc300c05d05b3
Fixed in
  • 791941be5da125d9a1b228582bfdc300c05d05b3
LinuxLinuxAffected
  • ≥ d38ceaf99ed015f2a0b9af3499791bd3a3daae21, < 91fbb5e635c8fb1b49e15c19da06480089ef719f
Fixed in
  • 91fbb5e635c8fb1b49e15c19da06480089ef719f
LinuxLinuxAffected
  • ≥ d38ceaf99ed015f2a0b9af3499791bd3a3daae21, < 40df11255d71b02e20e70579f1b12b687e396e26
Fixed in
  • 40df11255d71b02e20e70579f1b12b687e396e26
LinuxLinuxAffected
  • ≥ d38ceaf99ed015f2a0b9af3499791bd3a3daae21, < 8ae8b9e74bab94aab1d79f1688129bcc61c8b29a
Fixed in
  • 8ae8b9e74bab94aab1d79f1688129bcc61c8b29a

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)

References

Community reviews

Loading reviews…