CVE-2026-53374

What it actually does

This Linux kernel flaw affects the AMDGPU driver’s Graphics Address Remapping Table (GART) handling. When kernel GPU memory mappings are created, the GART page table is allocated without being fully initialized. Because the GPU translation lookaside buffer may speculatively cache adjacent uninitialized page-table entries, stale or garbage entries can be treated as valid GPU mappings. A local user with access to AMD GPU device interfaces may be able to influence GPU memory mappings and cause unauthorized GPU memory access, memory corruption, data exposure, or GPU/kernel instability. The CVSS vector indicates local exploitation with low privileges, no user interaction, and potential high confidentiality, integrity, and availability impact with scope change.

Why it matters to the business

Systems using vulnerable Linux kernels with AMDGPU enabled may be exposed to local privilege-boundary abuse, data leakage through GPU-accessible memory, workload corruption, or denial of service from GPU resets or crashes. This is most relevant for workstations, GPU-enabled servers, VDI hosts, CI/build systems, and multi-user compute environments where untrusted or semi-trusted users can access AMD GPU devices. It is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so prioritization should be risk-based but still timely for shared GPU systems because successful exploitation could affect other users or workloads on the same host.

How an attack unfolds

An attacker first needs local access to a Linux system where the vulnerable AMDGPU kernel driver is loaded and the attacker can interact with GPU device nodes, commonly through DRM render or card interfaces. The attacker then performs GPU buffer and mapping operations that cause the driver to allocate or update GART page-table entries. Because the GART table was not zero-initialized at allocation time and the GART TLB is not flushed after every mapping operation, the GPU may speculatively cache uninitialized entries from the same cache line. If those entries appear valid, later updates can cause the GPU to use stale mappings. Depending on memory layout and GPU activity, this can result in access to unintended memory, corruption of GPU-visible memory, GPU faults, or system instability. Reliable exploitation is hardware-, driver-, and workload-dependent, but the vulnerability is local and does not require user interaction once the attacker has access.

How to fix it

Apply a Linux kernel update that includes the AMDGPU fix to zero-initialize the GART table immediately after allocation using the appropriate GART PTE flags. The upstream fix is associated with commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24 and downstream distributions may backport it under their own kernel package versions. Because no exact affected products or fixed package versions were supplied, use the vendor or distribution advisory for the running kernel branch to identify the corrected package. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting membership in groups that can access /dev/dri devices, disabling unneeded GPU access for untrusted users and containers, isolating GPU workloads by trust level, and considering temporary removal or disablement of AMDGPU on systems where GPU acceleration is not required.

How to confirm the fix worked

Confirm that the running kernel package includes the AMDGPU GART zero-initialization patch or a vendor backport of commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24. Validate both the installed package and the actively booted kernel, since Linux systems may retain older kernels after package installation. Check distribution changelogs, kernel build metadata, and source package patches for the AMDGPU GART fix. After remediation, reboot into the fixed kernel and verify that the AMDGPU module is loaded from that kernel. Operationally, monitor for a reduction in unexplained AMDGPU VM faults, GPU resets, ring timeouts, or graphics/compute workload instability. If mitigating rather than patching, confirm that untrusted users and containers cannot open AMD GPU DRM device nodes.

Typical attack path

1. Gain local, low-privileged access to a Linux host using the AMDGPU driver.
2. Confirm AMD GPU device access through DRM device nodes such as render or card interfaces.
3. Trigger GPU buffer creation and mapping operations that allocate or modify GART page-table entries.
4. Rely on uninitialized GART entries being speculatively loaded into the GPU TLB and later reused as valid stale mappings.
5. Use the unintended mapping behavior to attempt GPU memory disclosure, memory corruption, workload manipulation, or denial of service.
6. Cover activity among normal GPU workload noise or repeated GPU reset/fault events.

How to detect it

There is no single reliable log entry that proves exploitation of this issue, because the flaw is a low-level GPU memory-mapping bug and successful abuse may look like normal GPU faults or instability. Detection should focus on correlating local user activity with AMDGPU error patterns. Review kernel logs from journalctl, dmesg, syslog, and centralized Linux logging for AMDGPU VM faults, protection faults, ring timeouts, GPU resets, and GPU job timeouts. Correlate those events with processes that opened /dev/dri/card* or /dev/dri/renderD*, recent interactive logins, container starts, GPU compute jobs, graphics workloads, and crashes. On shared systems, inspect auditd, eBPF, or EDR telemetry for untrusted users repeatedly accessing DRM render nodes shortly before AMDGPU faults. Memory forensics is unlikely to provide a clean signature, but repeated GPU faults following unusual local GPU workloads should be investigated. Because no public exploit maturity or named threat actors were supplied, detection should emphasize anomaly hunting rather than matching a known exploit signature.

• amdgpu: GPU fault detected
• amdgpu: VM fault
• VM_CONTEXT
• GCVM_L2_PROTECTION_FAULT_STATUS
• GCVM_L2_PROTECTION_FAULT_ADDR
• amdgpu_job_timedout
• ring gfx timeout
• ring compute timeout
• GPU reset begin
• GPU reset succeeded
• amdgpu: failed to clear page tables
• /dev/dri/renderD
• /dev/dri/card

What your security team should do

• Inventory Linux systems with AMD GPUs and the amdgpu kernel driver enabled, prioritizing multi-user servers, shared workstations, GPU compute nodes, VDI hosts, and container platforms exposing /dev/dri.
• Patch affected systems to a vendor-supported kernel containing the AMDGPU GART zero-initialization fix, and reboot to ensure the fixed kernel is active.
• Until patched, restrict access to /dev/dri/card* and /dev/dri/renderD* to trusted users and workloads only.
• Review container, VM, and job-scheduler configurations to ensure AMD GPU devices are not passed through to untrusted workloads unnecessarily.
• Search recent kernel logs for AMDGPU VM faults, GPU resets, ring timeouts, or abnormal GPU job failures that could indicate attempted abuse or instability caused by the flaw.
• Treat suspicious local GPU access in combination with crashes, resets, or unexplained memory corruption as a host-level investigation requiring process, user, and workload correlation.
• Track distribution advisories for exact fixed kernel package versions because the supplied data does not enumerate per-product fixed versions.