CVE-2026-53374 has been assigned to a flaw in the Linux kernel’s
The issue is not a vulnerability in AMD’s Windows display driver stack, and nothing in the NVD record identifies Windows 10, Windows 11, Radeon Software, or AMD Adrenalin Edition as affected products. It matters to Windows-focused IT teams chiefly where Linux is part of the estate: dual-boot engineering workstations, Linux GPU compute nodes, Hyper-V or other virtualized Linux guests with GPU passthrough, and appliance-style deployments built on Linux.
NIST’s National Vulnerability Database published the record on July 19, 2026, drawing its description and fixes from kernel.org. The record has no NVD-assigned CVSS score, attack vector, weakness classification, or public exploitation information as of July 20. That absence is important: this is a kernel-driver correctness defect now tracked as a CVE, not evidence of a confirmed real-world compromise campaign.
The defect sits in
According to the kernel.org description reproduced by NVD, the driver flushes the relevant GART translation lookaside buffer after unmapping memory, but not after mapping it. The allocation path used by
Those leftover values might look like valid mappings. If software later writes another PTE in that same cache line, the GPU could continue using a stale, garbage entry already loaded in the TLB rather than the intended state. In plain language, the driver could make a newly allocated GPU page table briefly resemble an old and invalid one.
That is why the patch is more than a cosmetic cleanup. Page-table initialization is foundational to predictable memory translation, and GPU drivers operate below the level where ordinary applications can safely correct bad state themselves. The CVE description does not claim arbitrary code execution, privilege escalation, or data disclosure; it describes a stale-mapping condition that kernel maintainers have resolved before assigning a severity.
This matters because the seemingly obvious alternative is unavailable. The CVE notes that
The original patch was posted by AMD engineer Philip Yang to the AMD graphics mailing list on April 28. In that discussion, the allocation was characterized as roughly 1 MB and initialized once, making a CPU-side clear a sensible trade-off. The fix was then pulled into the DRM tree and backported across the stable kernel branches now listed by NVD.
For IT teams, the useful takeaway is that this is not a mitigation that depends on a configuration toggle, an application update, or a firmware setting. The remediation is the kernel update. If a distribution has backported the patch into a vendor kernel with a different version string, its security advisory—not the upstream version number alone—should be treated as the authority.
Conversely, a Linux host can be affected even when it is not a conventional desktop. GPU-enabled build servers, render farms, workstations running ROCm-related workloads, and virtual machines using direct device assignment deserve the same patch review as a Linux laptop with an AMD Radeon GPU. Where
A quick local review begins with
The distinction becomes less tidy in mixed environments. A developer may use Windows 11 as the primary OS but boot native Linux for graphics development. A Windows Server host may run a Linux guest attached to a physical AMD GPU. A lab can have Windows endpoints administering Linux GPU systems through Windows Admin Center, SSH, RMM tooling, or CI/CD infrastructure. In all three cases, the Windows machine may be operationally adjacent to the risk while the Linux kernel is the component that needs replacement.
WSL users should also resist the reflex to equate every Linux CVE with WSL exposure. The record is specific to the upstream AMDGPU kernel driver and its GART handling; it does not identify Microsoft’s WSL GPU virtualization path or Windows’ DirectX stack. Organizations using specialized or experimental hardware-access configurations should validate their design, but standard WSL GPU acceleration is not named by this advisory.
Administrators should also avoid overstating the incident internally. NVD has published the CVE and enumerated affected upstream versions, but it has not provided a CVSS assessment or described known exploitation. The appropriate posture is measured patch hygiene: prioritize systems with AMD GPUs and sensitive workloads, update through supported distribution channels, and verify that the new kernel is running.
The next meaningful change will be vendor advisories and NVD enrichment. Until a severity assessment or additional technical analysis appears, CVE-2026-53374 is best treated as a resolved AMDGPU memory-translation defect with clear upstream fixes—not as a confirmed threat to Windows endpoints.
amdgpu driver that could leave stale, uninitialized entries in the GPU’s Graphics Address Remapping Table, or GART. The practical response for administrators is straightforward: update Linux systems using AMD GPUs to a kernel containing the fix—Linux 6.1.175, 6.6.140, 6.12.90, 6.18.32, 7.0.9, or a newer maintained build.The issue is not a vulnerability in AMD’s Windows display driver stack, and nothing in the NVD record identifies Windows 10, Windows 11, Radeon Software, or AMD Adrenalin Edition as affected products. It matters to Windows-focused IT teams chiefly where Linux is part of the estate: dual-boot engineering workstations, Linux GPU compute nodes, Hyper-V or other virtualized Linux guests with GPU passthrough, and appliance-style deployments built on Linux.
NIST’s National Vulnerability Database published the record on July 19, 2026, drawing its description and fixes from kernel.org. The record has no NVD-assigned CVSS score, attack vector, weakness classification, or public exploitation information as of July 20. That absence is important: this is a kernel-driver correctness defect now tracked as a CVE, not evidence of a confirmed real-world compromise campaign.
A page-table problem inside the AMDGPU driver
The defect sits in drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c, within code that creates the GART table. GART is a GPU memory-management mechanism: it gives the GPU a table of page-table entries, or PTEs, that map addresses used for graphics and compute workloads.According to the kernel.org description reproduced by NVD, the driver flushes the relevant GART translation lookaside buffer after unmapping memory, but not after mapping it. The allocation path used by
amdgpu_bo_create_kernel() did not automatically clear the buffer. That created a narrow but undesirable state in which a write to one PTE could lead the GPU’s TLB to speculatively read neighboring, uninitialized entries from the same cache line.Those leftover values might look like valid mappings. If software later writes another PTE in that same cache line, the GPU could continue using a stale, garbage entry already loaded in the TLB rather than the intended state. In plain language, the driver could make a newly allocated GPU page table briefly resemble an old and invalid one.
That is why the patch is more than a cosmetic cleanup. Page-table initialization is foundational to predictable memory translation, and GPU drivers operate below the level where ordinary applications can safely correct bad state themselves. The CVE description does not claim arbitrary code execution, privilege escalation, or data disclosure; it describes a stale-mapping condition that kernel maintainers have resolved before assigning a severity.
The fix clears the table before it can be used
The repair is deliberately direct. The patched driver initializes the newly allocated GART table immediately with the GPU’s standardgart_pte_flags value, using memset_io() in the stable backport described by NVD. The goal is to ensure every entry has a defined invalid-or-safe state before any individual mapping is installed.This matters because the seemingly obvious alternative is unavailable. The CVE notes that
AMDGPU_GEM_CREATE_VRAM_CLEARED cannot be used to clear the allocation through the SDMA engine: SDMA depends on a functioning GART mapping in the first place. Using the GPU’s own DMA machinery to initialize the table would therefore create a bootstrapping problem.The original patch was posted by AMD engineer Philip Yang to the AMD graphics mailing list on April 28. In that discussion, the allocation was characterized as roughly 1 MB and initialized once, making a CPU-side clear a sensible trade-off. The fix was then pulled into the DRM tree and backported across the stable kernel branches now listed by NVD.
For IT teams, the useful takeaway is that this is not a mitigation that depends on a configuration toggle, an application update, or a firmware setting. The remediation is the kernel update. If a distribution has backported the patch into a vendor kernel with a different version string, its security advisory—not the upstream version number alone—should be treated as the authority.
The affected-version list needs careful reading
NVD identifies versions earlier than the following stable releases as affected:- Linux 6.1.x is fixed beginning with 6.1.175.
- Linux 6.6.x is fixed beginning with 6.6.140.
- Linux 6.12.x is fixed beginning with 6.12.90.
- Linux 6.18.x is fixed beginning with 6.18.32.
- Linux 7.0.x is fixed beginning with 7.0.9.
Conversely, a Linux host can be affected even when it is not a conventional desktop. GPU-enabled build servers, render farms, workstations running ROCm-related workloads, and virtual machines using direct device assignment deserve the same patch review as a Linux laptop with an AMD Radeon GPU. Where
amdgpu is loaded, administrators should check the running kernel, not simply the package version shown in an inventory database.A quick local review begins with
uname -r, but that only identifies the distribution’s kernel label. Debian, Ubuntu, Red Hat, SUSE, Oracle Linux, and cloud-image kernels often carry security fixes through backports while retaining a vendor-specific version scheme. SUSE, for example, has already listed “drm/amdgpu: zero-initialize GART table on allocation” in a June Linux kernel security update. The distribution changelog or advisory is the reliable confirmation.Windows fleets are mostly in the oversight lane
For ordinary Windows PCs, this CVE should not trigger an AMD Adrenalin deployment, a Windows cumulative update escalation, or a BIOS refresh. Windows uses AMD’s Windows kernel-mode display driver rather than the Linux kernel’samdgpu DRM source file named in the CVE.The distinction becomes less tidy in mixed environments. A developer may use Windows 11 as the primary OS but boot native Linux for graphics development. A Windows Server host may run a Linux guest attached to a physical AMD GPU. A lab can have Windows endpoints administering Linux GPU systems through Windows Admin Center, SSH, RMM tooling, or CI/CD infrastructure. In all three cases, the Windows machine may be operationally adjacent to the risk while the Linux kernel is the component that needs replacement.
WSL users should also resist the reflex to equate every Linux CVE with WSL exposure. The record is specific to the upstream AMDGPU kernel driver and its GART handling; it does not identify Microsoft’s WSL GPU virtualization path or Windows’ DirectX stack. Organizations using specialized or experimental hardware-access configurations should validate their design, but standard WSL GPU acceleration is not named by this advisory.
Patch the driver, then verify the reboot boundary
Because this is a kernel-level correction, installing the package is only half the job. The system must be booted into the updated kernel before the corrected AMDGPU driver is active. On persistent Linux infrastructure, that means checking the active kernel after the maintenance window rather than accepting package-manager success as proof of remediation.Administrators should also avoid overstating the incident internally. NVD has published the CVE and enumerated affected upstream versions, but it has not provided a CVSS assessment or described known exploitation. The appropriate posture is measured patch hygiene: prioritize systems with AMD GPUs and sensitive workloads, update through supported distribution channels, and verify that the new kernel is running.
The next meaningful change will be vendor advisories and NVD enrichment. Until a severity assessment or additional technical analysis appears, CVE-2026-53374 is best treated as a resolved AMDGPU memory-translation defect with clear upstream fixes—not as a confirmed threat to Windows endpoints.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:02:39-07:00
NVD - CVE-2026-53374
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:02:39-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
