CVE-2026-53143

What it actually does

This is a Linux kernel amdkfd driver buffer overflow affecting AMD GPU KFD SDMA queue checkpoint and restore handling on GFX11/Navi3x hardware. The v11 MQD manager used compute-queue checkpoint/restore routines for SDMA queues, causing 2048-byte operations against a 512-byte SDMA MQD structure. During checkpoint, this can over-read 1536 bytes of adjacent GPU GTT memory and expose it to userspace. During restore, it can over-write 1536 bytes of adjacent GTT memory, potentially corrupting neighboring GPU queue descriptors, ring buffers, or related kernel/GPU driver state. The most direct impact is local information disclosure and memory corruption through CRIU-based checkpoint/restore paths involving AMD KFD SDMA queues.

Why it matters to the business

Systems using affected Linux kernels with AMD GFX11/Navi3x GPUs and KFD/ROCm-style GPU compute workloads could be exposed to local data leakage or instability if untrusted users can create and checkpoint/restore GPU queues. In multi-user GPU compute, AI/ML, HPC, or containerized GPU environments, this could undermine workload isolation, leak data from adjacent GPU memory, or cause job failures and node instability. The currently reported exploitation likelihood is low, with no known CISA KEV listing and no public exploit maturity indicated, but GPU compute infrastructure should still prioritize kernel updates where untrusted or shared workloads are present.

How an attack unfolds

An attacker needs local access to a system using an affected Linux kernel, AMD KFD support, and a GFX11/Navi3x AMD GPU. They create or control an SDMA queue through the AMD KFD interface and trigger the CRIU checkpoint path. Because the driver mistakenly treats the SDMA MQD as a larger compute MQD, the kernel copies 2048 bytes from a 512-byte SDMA MQD allocation, leaking adjacent GTT memory into a userspace checkpoint image or related userspace buffer. For the restore path, the attacker supplies or triggers restoration data sized for the larger compute MQD, causing the kernel to write beyond the SDMA MQD allocation and corrupt adjacent GTT memory. Practical exploitation depends on local GPU access, availability of checkpoint/restore functionality, memory layout, driver configuration, and the attacker’s ability to influence queue creation and restore data. Likely outcomes include sensitive data exposure from neighboring GPU allocations, denial of service through GPU/job corruption, and potentially further privilege-impacting behavior if adjacent corrupted GPU driver structures can be controlled.

How to fix it

Upgrade to a Linux kernel build that includes the amdkfd fix from upstream commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c or the corresponding vendor backport. Because exact affected and fixed package versions vary by Linux distribution and kernel branch, use the distribution security advisory or kernel changelog to confirm inclusion of the fix for the drm/amdkfd v11 SDMA MQD checkpoint/restore issue. Where immediate patching is not possible, reduce exposure by restricting local access to AMD KFD/DRM GPU device nodes to trusted users only, disabling or limiting untrusted CRIU checkpoint/restore of GPU workloads, isolating shared GPU workloads onto patched nodes, and avoiding multi-tenant GPU compute on affected kernels. If GPU compute is not required, consider disabling AMD KFD/ROCm access or unloading/preventing the relevant driver stack where operationally feasible.

How to confirm the fix worked

Confirm the running kernel contains the vendor backport or upstream fix that adds v11 SDMA-specific checkpoint_mqd_sdma() and restore_mqd_sdma() handling in drm/amdkfd. Validate through package metadata, distribution advisories, kernel source/changelog review, or symbol/source inspection of the installed kernel build. Confirm whether exposure exists by checking for AMD GFX11/Navi3x GPUs, loaded amdgpu/amdkfd functionality, accessible /dev/kfd and /dev/dri render nodes, and CRIU or GPU checkpoint/restore usage. After remediation, verify systems are running the patched kernel, not merely that a patched package is installed, and reboot into the fixed kernel if required. In shared compute environments, also validate that device-node permissions and workload scheduling policies prevent untrusted users from accessing vulnerable GPU checkpoint/restore paths on any remaining unpatched nodes.

Typical attack path

1. Gain local execution on a Linux system with an affected kernel, AMD KFD enabled, and GFX11/Navi3x AMD GPU hardware.
2. Obtain permission to access AMD GPU compute interfaces, commonly via device nodes such as /dev/kfd and relevant /dev/dri devices.
3. Create or interact with an SDMA queue through the AMD KFD/HSA/ROCm stack.
4. Trigger CRIU checkpoint handling for the SDMA queue to cause an oversized read from the 512-byte SDMA MQD buffer and recover adjacent GTT memory in userspace-accessible checkpoint data.
5. Optionally trigger CRIU restore handling with crafted or controlled queue state to cause an oversized write into the SDMA MQD allocation.
6. Use the resulting memory disclosure for sensitive data recovery or use memory corruption to disrupt GPU workloads, crash the driver/node, or attempt deeper exploitation depending on memory layout and adjacent objects.

How to detect it

There are no reliable public exploit-specific indicators for this issue. Detection should focus on evidence that the vulnerable path was exercised and on secondary signs of GPU memory corruption. Review kernel logs, system journal, audit logs, container/job scheduler logs, CRIU logs, and GPU workload logs for checkpoint or restore operations involving AMD KFD/ROCm workloads, especially by untrusted users. Look for amdgpu or amdkfd warnings, GPU resets, ring-buffer errors, queue faults, VM faults, kernel oops messages, or sudden failures around the same time as CRIU checkpoint/restore activity. Audit access to /dev/kfd and /dev/dri render nodes, and correlate device access with CRIU invocations or suspicious checkpoint image creation. For forensics, preserve CRIU image directories created by untrusted users, relevant shell/process history, kernel logs, and scheduler/container runtime events. Because checkpoint exploitation may copy adjacent GTT memory into userspace artifacts, treat checkpoint images from suspicious activity as sensitive and inspect them only in controlled forensic workflows.

What your security team should do

• Inventory Linux systems with AMD GFX11/Navi3x GPUs, amdgpu/amdkfd enabled, ROCm/HSA workloads, CRIU usage, or shared GPU compute access.
• Prioritize patching shared, multi-user, containerized, HPC, AI/ML, and cloud GPU nodes where untrusted users can access /dev/kfd or /dev/dri devices.
• Upgrade to a vendor kernel containing the upstream amdkfd SDMA MQD checkpoint/restore fix, then reboot into the fixed kernel and verify the running version.
• Until patched, restrict /dev/kfd and relevant /dev/dri render-node access to trusted users and disable untrusted GPU checkpoint/restore workflows where feasible.
• Review GPU compute nodes for unexplained amdgpu resets, kernel oops events, CRIU checkpoint/restore activity, or abnormal job failures that may indicate attempted triggering.
• Treat suspicious checkpoint artifacts from untrusted users as potentially containing leaked GPU/GTT memory and handle them as sensitive data.
• Monitor vendor advisories for exact fixed kernel package versions because fixed versions were not provided in the input data.