CVE-2026-53143: Linux AMD GPU Driver Buffer Overflow in SDMA Queue Management

Technical summary

The v11 MQD (Memory Queue Descriptor) manager in drm/amdkfd contains a copy-paste error where KFD_MQD_TYPE_SDMA queues are assigned checkpoint_mqd and restore_mqd function pointers intended for compute queues. These functions operate on struct v11_compute_mqd (2048 bytes) rather than the correct struct v11_sdma_mqd (512 bytes). During CRIU checkpoint operations, checkpoint_mqd reads beyond the 512-byte SDMA buffer boundary, leaking 1536 bytes of GTT (Graphics Translation Table) memory to userspace. During restore, restore_mqd writes 1536 bytes past the buffer boundary, corrupting adjacent GPU memory structures including ring buffers or neighboring MQDs. The fix introduces SDMA-specific checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller structure size, aligning v11 behavior with v9, v10, and v12 backends that already implement this correctly.

Business impact

Organizations deploying containerized GPU workloads or using kernel checkpoint/restore (CRIU) with AMD Navi3x GPUs face information disclosure and memory corruption risks. A local attacker with access to CRIU operations could read sensitive GPU memory (encryption keys, buffers from other processes) or crash GPU compute contexts by corrupting adjacent queue descriptors. In shared GPU environments (cloud providers, research clusters), this enables cross-tenant data leakage. GPU workload availability may be impacted through deliberate corruption of queue state, affecting compute-intensive applications and ML inference pipelines.

Affected systems

Linux kernel systems with AMD Navi3x (RDNA3) GPUs running the amdkfd driver. Vulnerability is triggered when CRIU checkpoint/restore operations are performed on SDMA (System DMA) queues. Systems not using CRIU or those without SDMA queue usage are not directly exploitable, though the kernel flaw exists in the codebase. The vulnerability is specific to v11 MQD manager; earlier (cik, vi, v9, v10) and later (v12) ASIC backends are not affected due to correct SDMA-specific function assignments.

Exploitability

Exploitation requires local access and ability to trigger CRIU checkpoint/restore on SDMA queues. This is not exploitable remotely. In containerized or HPC environments where users have direct GPU access or can trigger container checkpointing, a local attacker can reliably read or corrupt GPU memory. No special privileges beyond local user access are required due to the CVSS vector (PR:L). Exploitation is deterministic—the overflow occurs on every affected checkpoint or restore call—making it straightforward for a motivated attacker to extract data or destabilize GPU workloads.

Remediation

Apply a kernel patch that replaces the incorrect function pointer assignments with SDMA-specific variants (checkpoint_mqd_sdma and restore_mqd_sdma). The fix is straightforward and low-risk as it corrects a clear copy-paste error. Systems should update to a patched kernel version once available from their distribution. Temporary mitigation is limited; organizations can disable CRIU checkpoint/restore for untrusted users or restrict GPU access until patched. No workaround addresses the root cause without code changes.

Patch guidance

Monitor your Linux distribution's security advisories for kernel updates addressing CVE-2026-53143. The fix involves adding two new functions to the v11 MQD manager and correcting the function pointer table to use them for SDMA queues. Verify patches against the upstream commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c in the Linux kernel repository. When patches are available, prioritize systems running Navi3x GPUs with CRIU enabled. Test patches in a staging environment before production rollout to ensure no regressions with GPU compute workloads. Kernel maintainers typically backport fixes to stable branches (6.1, 6.6, 6.10, etc.), so check your distribution's kernel version and corresponding stable-branch availability.

Detection guidance

Detection is challenging as the vulnerability requires kernel-level access to observe. Monitor system logs for unexpected GPU memory errors or CRIU checkpoint/restore failures on systems with Navi3x GPUs. GPU drivers may emit warnings about corrupted MQD state or ring buffer corruption, though these are not guaranteed. Network intrusion detection will not catch local exploitation. Forensic analysis would require capturing GPU memory state during checkpoint/restore operations, which requires specialized GPU debugging tools. Proactive approach: verify kernel versions in your inventory and identify systems with both Navi3x GPUs and CRIU enabled; prioritize patching those systems.

Why prioritize this

This vulnerability merits high priority due to its combination of high CVSS score (7.8), deterministic exploitability, and impact on confidentiality and integrity in shared GPU environments. The presence of both memory leakage (CWE-131, Incorrect Buffer Size Calculation) and buffer overflow (CWE-787) adds severity. While exploitation requires local access, the prevalence of GPU acceleration in cloud and HPC settings increases attack surface. Organizations with multi-tenant GPU sharing or container orchestration should treat this as critical and prioritize patching. The fix is low-complexity and poses minimal regression risk, making remediation straightforward.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects local attack vector, low attack complexity, low privilege requirement, and high impact across confidentiality, integrity, and availability. The buffer overflow allows an attacker to read adjacent memory (information disclosure) and write to adjacent memory (corruption). In scenarios without CRIU usage, the practical risk is lower; however, in GPU-heavy environments (cloud, ML platforms, research institutions), the risk is amplified due to multi-tenancy and shared resource contention. The vulnerability is not currently known to be exploited in the wild (KEV status: false), but the technical simplicity of exploitation and high-value targets (GPU workloads, encryption keys) suggest active exploitation is likely once public awareness increases.

Frequently asked questions