CVE-2026-46229: Linux KFD VRAM Stale Data Exposure in AMD GPU Compute

Technical summary

The vulnerability stems from an incomplete flag configuration in the KFD VRAM allocation path. While KFD correctly sets AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE to erase data when buffers are freed, it neglects to set AMDGPU_GEM_CREATE_VRAM_CLEARED during initial allocation. This flag, which is consistently applied by the standard GEM ioctl path (amdgpu_gem_create_ioctl and amdgpu_mode_dumb_create), ensures VRAM pages are zeroed before being handed to userspace. Without this flag, newly allocated VRAM retains stale page table entries and other residual kernel data. Compute kernels running under KFD can read these uninitialized values, leading to data disclosure and potential memory corruption in protocol-sensitive operations.

Business impact

Organizations running GPU-accelerated HPC workloads or AI/ML pipelines on AMD hardware may experience unexpected application failures and data integrity issues. RCCL-based multi-GPU communications can fail due to corrupted handshake fields (ptrExchange, head, tail), disrupting distributed training and inference jobs. While the vulnerability does not directly expose user-controlled data across security boundaries, it creates instability in production compute environments and can lead to silent data corruption if applications do not detect protocol violations. The scope is primarily isolated to the affected system, but for large-scale HPC centers or cloud GPU providers, widespread node failures could impact service availability.

Affected systems

Linux systems equipped with AMD Radeon GPUs that use the KFD driver for compute workloads. This includes AMD RDNA and CDNA GPU architectures running Linux kernels with the vulnerable KFD code path. Affected environments typically include HPC clusters, data centers running GPU-accelerated AI workloads, and systems using RCCL for multi-GPU coordination. Consumer systems with AMD discrete GPUs may also be affected if they execute GPGPU compute kernels through KFD, though traditional graphics-only workloads are less likely to trigger the vulnerability. AMD APUs with integrated Radeon graphics used for compute are not typically affected unless actively using KFD compute features.

Exploitability

This vulnerability requires local code execution with unprivileged user privileges to trigger. An attacker must launch a compute kernel through KFD that attempts to read from newly allocated GPU VRAM. No network vector exists; exploitation is limited to authenticated local users or containerized workloads on shared systems. The barrier to exploitation is low—any user with compute access can write a simple GPGPU kernel to probe allocated memory. However, weaponizing the stale data leak for practical attacks depends on whether sensitive kernel state (page table entries, encryption keys, or other secrets) happens to reside in freed VRAM at the time of allocation, making reliability and reproducibility challenges. The primary manifestation is denial of service through application crashes rather than direct privilege escalation or confidentiality breach.

Remediation

The fix involves adding the AMDGPU_GEM_CREATE_VRAM_CLEARED flag to KFD allocation calls, ensuring all GPU VRAM is zero-initialized before use. This aligns KFD behavior with the standard GEM ioctl path and eliminates the stale data exposure. The patch modifies the kernel-side KFD memory allocation logic; no userspace changes or configuration tuning is required. Organizations should prioritize patching on systems running active GPU compute workloads. For environments where KFD is not used or GPU compute is disabled, the risk is minimal.

Patch guidance

Apply the Linux kernel patch that adds VRAM_CLEARED flag initialization to the KFD allocation pathway. Verify against official Linux kernel security advisories and your Linux distribution's kernel security updates for specific version numbers and release schedules. Test patched kernels in a staging environment on GPU-compute-enabled systems to confirm no performance regression or driver instability. For distributions using long-term support kernels (e.g., RHEL, Ubuntu LTS, SLES), monitor vendor advisories for backported patches. GPU driver user-mode libraries (ROCm, AMDGPU Pro) may require corresponding updates; consult AMD's release notes to ensure compatibility. Reboot systems post-kernel-patch to activate the fix.

Detection guidance

Detection of exploitation attempts is difficult without kernel instrumentation, as the vulnerability manifests as application crashes rather than clear security events. Monitor GPU compute job logs for unexplained segmentation faults or RCCL handshake timeouts on multi-GPU systems. Examine kernel logs for KFD-related errors or allocation failures. In high-security environments, enable CONFIG_DEBUG_OBJECTS and memory tagging extensions (MTE) if available to catch uninitialized memory reads. Workload profiling tools can detect abnormal memory access patterns in compute kernels. However, proactive patching is more reliable than detection; this is not a vulnerability where behavioral indicators are reliably logged by default.

Why prioritize this

Although rated CVSS 5.5 (Medium), this vulnerability merits expedited patching in HPC and AI/ML environments because: (1) Impact scope includes data integrity and availability of critical workloads, (2) exploitability is trivial for any local user with compute access, (3) manifestations (crashes, RCCL failures) can cascade across distributed training jobs, and (4) the fix is non-invasive and carries low regression risk. Organizations with light GPU usage or no KFD compute workloads can safely deprioritize. Those running dense GPU clusters or multi-tenant Kubernetes environments with GPU access should prioritize within their standard patch cycle.

Risk score, explained

The CVSS 5.5 reflects local attack vector, low privileges required, high availability impact (denial of service via crash), and no confidentiality or integrity impact under the standard scoring assumptions. However, practical risk is contextual: in isolated single-user GPU systems, impact is low; in shared HPC clusters where GPU access is compartmentalized, a malicious user crashing a job affects their own workload or a shared queue. The lack of KEV consideration and the information-disclosure component (stale kernel memory potentially visible to compute kernels) suggest this was rated conservatively, assuming the exposed data is non-critical. Organizations should adjust priority based on multi-tenancy posture and GPU compute criticality.

Frequently asked questions