CVE-2026-46229

What it actually does

This Linux kernel flaw affects AMD GPU compute memory allocation through the KFD/amdkfd path. VRAM allocated for compute workloads was marked to be wiped on release, but not explicitly cleared before being handed to a new user. As a result, newly allocated GPU memory could contain stale data from a prior allocation. The described practical impact is availability-related: unexpected non-zero stale values in RCCL peer-to-peer transport structures can corrupt protocol state and crash GPU communication workloads. Depending on workload and tenancy model, stale VRAM exposure may also create a data-residue risk between local users or jobs that share the same GPU resources.

Why it matters to the business

Organizations running AMD GPU compute workloads on affected Linux kernels may experience instability, failed distributed GPU jobs, or crashes in high-performance computing, AI/ML, and other accelerator-dependent workloads. In shared GPU environments, the issue also raises concern that one local user or job could observe remnants of memory previously used by another workload. The CVSS score is moderate and EPSS is very low, there is no known KEV listing, and no public exploit maturity is reported, so urgency is highest for multi-user GPU systems, cluster nodes, and production systems using AMD KFD/ROCm workloads rather than general-purpose Linux servers without AMD GPU compute use.

How an attack unfolds

An attacker needs local access with the ability to submit AMD GPU compute work through the affected KFD interface. They cause or wait for VRAM to be used by another workload, then request fresh VRAM allocations through the KFD path. Because the allocation path did not set the flag that clears VRAM before reuse, the attacker’s compute kernel may receive memory pages containing stale contents from a prior allocation. The attacker can inspect those buffers from GPU code or user-space mappings to look for residual data, or intentionally trigger corruption conditions that cause GPU communication libraries such as RCCL to fail when stale non-zero values appear in expected-zero control structures. Exploitation is local, requires privileges sufficient to access the GPU compute device, and is most relevant on shared AMD GPU compute hosts.

How to fix it

Upgrade to a Linux kernel version that includes the amdkfd fix to mark KFD VRAM allocations as cleared on allocation, not only wiped on release. If using vendor kernels, install the relevant distribution or appliance kernel security update when available. No exact fixed versions were provided in the input, so remediation should be tracked through the operating system vendor’s kernel advisory for this issue. As interim risk reduction, restrict local access to AMD GPU compute devices, avoid sharing affected AMD GPU nodes between mutually untrusted users or jobs, drain and reboot GPU nodes between trust boundaries where practical, and disable or isolate KFD/ROCm compute access on systems that do not require it.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport for the amdkfd VRAM-clearing change. Validate that the kernel package version matches the fixed version published by the Linux distribution or hardware platform vendor. On affected AMD GPU compute hosts, verify that /dev/kfd access is limited to intended users or service accounts and that untrusted users cannot submit GPU workloads. Functional validation can include running AMD GPU compute/RCCL workloads that previously showed startup handshake failures or crashes and confirming stability after the patch. For source-based builds, confirm the KFD VRAM allocation path sets the VRAM-cleared behavior for userspace allocations in addition to wipe-on-release behavior.

Typical attack path

1. Gain local access to a system that exposes AMD GPU compute resources through the Linux KFD/amdkfd interface.
2. Identify that the system is running an affected Linux kernel and AMDGPU/KFD stack.
3. Allocate and release GPU VRAM repeatedly or time allocations after another workload has used VRAM.
4. Submit GPU compute kernels that read newly allocated buffers before the memory has been initialized by the application.
5. Inspect the buffers for stale data remnants or use the uninitialized non-zero values to induce protocol corruption or workload crashes.
6. Optionally repeat across multiple allocations to improve chances of observing useful residue or triggering availability impact.

How to detect it

There is no reliable network indicator for this issue because exploitation is local and occurs through GPU memory allocation behavior. Detection should focus on endpoint, kernel, and workload telemetry from AMD GPU compute systems. Review authentication and audit logs for local users or jobs with access to /dev/kfd, /dev/dri/render* devices, or GPU-related groups around the time of suspicious GPU workload failures. Examine kernel logs, system journals, ROCm/RCCL application logs, scheduler logs, and container runtime logs for repeated AMDGPU resets, KFD faults, RCCL P2P transport crashes, or protocol handshake failures involving unexpected non-zero control fields. Look for unusual local processes repeatedly allocating GPU memory or running short-lived compute kernels, especially from users or containers that do not normally use GPU resources. Because crashes can occur from benign workload instability, correlate log artifacts with user/job activity and device access rather than treating any single GPU reset as definitive compromise.

• /dev/kfd
• /dev/dri/renderD
• amdkfd
• AMDGPU
• amdgpu
• RCCL
• RCCL P2P
• ptrExchange
• head/tail
• GPU reset
• ring gfx timeout
• KFD
• ROCm
• HSA
• amdgpu: GPU fault
• amdgpu: ring
• amdgpu: failed
• kfd:
• rccl

What your security team should do

• Inventory Linux systems with AMD GPUs, ROCm, KFD/amdkfd, or exposed /dev/kfd devices.
• Prioritize patching shared GPU clusters, AI/ML platforms, HPC nodes, CI systems, and any multi-user hosts where AMD GPU compute resources are shared across trust boundaries.
• Apply the vendor kernel update that contains the amdkfd VRAM-clearing fix; if no vendor update is available, plan an update to a kernel containing the upstream fix once released by the platform vendor.
• Temporarily restrict membership in GPU/render/video access groups and enforce least privilege for /dev/kfd and AMD GPU device nodes.
• Avoid co-scheduling mutually untrusted workloads on the same affected AMD GPU host until patched.
• Monitor for unexplained RCCL, ROCm, amdgpu, or GPU reset failures that could indicate the flaw is being triggered, while recognizing that such symptoms are not proof of malicious exploitation.
• Document compensating controls for any GPU systems that cannot be patched promptly, including user isolation, job draining, node reboots between tenants, and reduced device access.