Skip to main content

Linux Kernel CVE-2026-53374

| EUVDEUVD-2026-45447 HIGH
2026-07-19 Linux GHSA-45w5-677j-gmrq
8.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Local GPU-node access (AV:L/PR:L); speculative uncontrolled TLB behavior makes it racy (AC:H); GPU crosses contexts (S:C) with likely info leak (C:H) but limited attacker-controlled integrity/availability impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:L
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 18:01 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
8.8 (HIGH)
Patch available
Jul 19, 2026 - 13:02 EUVD
CVE Published
Jul 19, 2026 - 10:01 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 19, 2026 - 10:01 cve.org
HIGH 8.8

DescriptionCVE.org

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)

AnalysisAI

Improper memory initialization in the Linux kernel's AMD GPU driver (drm/amdgpu) allows a stale, uninitialized GART page-table entry to be speculatively loaded into the GPU TLB, causing the GPU to reference the wrong physical memory. Affected are systems running AMD GPUs on kernels before 6.1.175, 6.6.140, 6.12.90, 6.18.32 and 7.0.9; a low-privileged local user with GPU access could potentially trigger disclosure of adjacent memory or corrupt GPU address translation. No public exploit identified at time of analysis, and EPSS is low (0.16%), consistent with a hardware-specific correctness flaw rather than a mass-exploitable bug.

Technical ContextAI

The issue lives in AMDGPU's GART (Graphics Address Remapping Table), the GPU's IOMMU-style translation layer that maps GPU virtual addresses to system/VRAM pages via page-table entries (PTEs). amdgpu_bo_create_kernel() returns the GART table buffer without zeroing it, so the memory contains prior garbage. Because the GART TLB is flushed only after unmapping and not after mapping, writing a single valid PTE can cause the GPU to speculatively pull adjacent uninitialized entries from the same cacheline into the TLB; those garbage bits can pass validity checks, and a later write to a neighboring PTE may make the GPU translate through a stale entry. The fix calls memset_io() to zero the table with gart_pte_flags immediately after allocation (AMDGPU_GEM_CREATE_VRAM_CLEARED cannot be used here because SDMA-based clearing itself depends on a working GART). The root cause is a use-of-uninitialized-memory / improper initialization class defect (CWE-908/CWE-909 family); NVD lists CWE as N/A.

RemediationAI

Vendor-released patch: upgrade to a fixed stable kernel - 6.1.175, 6.6.140, 6.12.90, 6.18.32, or 7.0.9 (and 7.1) or later - via your distribution's kernel update channel, then reboot so the corrected amdgpu driver is loaded. The corresponding upstream fix commits are available at https://git.kernel.org/stable/c/40df11255d71b02e20e70579f1b12b687e396e26 and the sibling stable commits (91fbb5e635c8, 8ae8b9e74bab, b17175d0a375, 791941be5da1, e6c2e6c2e1fa); see the advisory at https://vuldb.com/vuln/380106. If immediate patching is not possible, the practical compensating control is to restrict local access to GPU DRM device nodes (/dev/dri/renderD* and card*) to trusted users/groups, which reduces the local attack surface at the cost of breaking unprivileged GPU compute/rendering for restricted users; on multi-tenant or untrusted-local-user hosts, avoid exposing AMD GPU passthrough or shared render nodes until patched. There is no config toggle that disables the vulnerable code path without disabling the amdgpu driver itself.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

Share

CVE-2026-53374 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy