CVE-2026-53376

What it actually does

This is an improper input validation flaw in the Linux kernel AMD GPU compute driver, amdkfd. The affected ioctl path, kfd_ioctl_get_process_apertures_new, did not enforce an upper bound on num_of_nodes before using it in aperture-processing logic. A local process with access to the AMD KFD device interface could supply or influence values that cause the kernel driver to operate beyond expected node limits. Depending on kernel build, hardware configuration, and memory layout, likely outcomes include kernel memory corruption, kernel crash, or denial of service; privilege escalation or information disclosure cannot be ruled out for kernel memory-safety flaws, but no public exploit is currently reported.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU compute functionality may be vulnerable to local disruption or potential privilege escalation by users or workloads that can access the GPU compute device. The risk is lower for systems without AMD KFD enabled or where untrusted users cannot access /dev/kfd, and current public exploitation signals are low: EPSS is 0.00125, the issue is not in CISA KEV, is not marked as ransomware-used, and exploit maturity is listed as none. The main operational concern is instability or compromise of shared GPU servers, developer workstations, AI/ML compute nodes, HPC clusters, and multi-user Linux hosts where GPU device access is broadly granted.

How an attack unfolds

An attacker first needs local code execution on a Linux system running an affected kernel with the AMD KFD driver available, typically through shell access, a compromised user account, a malicious container with GPU device passthrough, or execution of an untrusted workload. The attacker checks whether /dev/kfd is present and accessible, then invokes the vulnerable KFD ioctl associated with process aperture discovery using crafted parameters or a crafted execution context that results in an excessive num_of_nodes value. Because the vulnerable kernel path lacks an upper bound check, the driver may process more nodes than the destination structure or logic safely supports. Successful exploitation is expected to produce kernel memory corruption or a kernel oops/panic, causing denial of service; with additional exploitation work, a local attacker may attempt to convert the memory corruption condition into elevated kernel privileges. There is no current indication of public weaponization, KEV listing, or known ransomware use for this issue.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the upstream amdkfd fix adding an upper bound check for num_of_nodes in kfd_ioctl_get_process_apertures_new. If exact fixed package versions are not available from the vulnerability record, rely on distribution advisories and kernel changelogs referencing the AMD KFD num_of_nodes upper-bound fix or upstream commit lineage associated with the patch. Prioritize GPU compute hosts, multi-user Linux systems, container platforms with GPU passthrough, AI/ML workers, HPC nodes, and developer workstations using AMD GPUs. If immediate patching is not possible, reduce exposure by restricting access to /dev/kfd and /dev/dri/renderD* to trusted users only, disabling AMD KFD/ROCm compute functionality where not required, preventing untrusted containers from receiving GPU device passthrough, and applying standard kernel hardening controls such as lockdown, module signing, unprivileged user namespace restrictions, and least-privilege device cgroup policies. A reboot is generally required after installing a fixed kernel to ensure the patched driver is active.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that packages are installed. Validate with uname -a, package manager kernel version output, and the distribution security advisory for this CVE or for the amdkfd num_of_nodes bound-check patch. Confirm the host has rebooted into the fixed kernel. Where source or debug symbols are available, verify that the amdkfd code path for kfd_ioctl_get_process_apertures_new enforces an upper bound before iterating or copying node aperture data. Check whether the system is exposed by confirming whether AMD KFD is active with lsmod | grep amdkfd, whether /dev/kfd exists, and whether untrusted users or containers have read/write access to /dev/kfd or /dev/dri/renderD*. On mitigated systems, verify device permissions, udev rules, container runtime device mappings, and group memberships prevent unintended access.

Typical attack path

1. Gain local code execution on a Linux host that has an affected AMD GPU/KFD kernel driver loaded.
2. Confirm that AMD KFD compute access is available, commonly by checking for /dev/kfd and related render devices under /dev/dri/.
3. Open the KFD device from an unprivileged or low-privileged process if permissions allow access.
4. Invoke the vulnerable get-process-apertures ioctl path with crafted inputs or conditions that cause an excessive node count to be processed.
5. Trigger out-of-bounds kernel driver behavior, leading to a kernel crash, denial of service, or potentially exploitable memory corruption.
6. If pursuing privilege escalation, iterate on memory layout and kernel hardening bypasses to attempt controlled corruption and execution with elevated privileges.

How to detect it

Look for signs of attempted local exploitation on systems with AMD KFD enabled. Primary data sources are kernel logs, system journal, audit logs, endpoint telemetry, crash dumps, container runtime logs, and GPU workload scheduler logs. Search for kernel oops, panic, KASAN, UBSAN, slab out-of-bounds, general protection fault, or page fault messages involving amdkfd, kfd_ioctl_get_process_apertures_new, /dev/kfd, or AMD GPU compute processes. Audit successful opens or ioctl-heavy access to /dev/kfd by unexpected users, service accounts, CI jobs, containers, or recently introduced binaries. Correlate suspicious /dev/kfd access with immediate kernel instability, GPU reset events, host reboots, or crash dump creation. On containerized systems, review pod/container specs and runtime events for unexpected mappings of /dev/kfd or /dev/dri/renderD*. Because exploitation would occur through a local kernel ioctl and no public exploit indicators are known, absence of logs does not prove absence of attempts; prioritize behavioral evidence such as anomalous device access followed by kernel faults.

• /dev/kfd
• /dev/dri/renderD
• amdkfd
• kfd_ioctl_get_process_apertures_new
• get_process_apertures_new
• KFD_IOC_GET_PROCESS_APERTURES_NEW
• BUG: kernel
• Oops:
• kernel panic
• general protection fault
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• UBSAN: array-index-out-of-bounds
• drivers/gpu/drm/amd/amdkfd
• amdgpu: GPU reset
• amdkfd:

What your security team should do

• Inventory Linux systems with AMD GPUs, ROCm, amdkfd loaded, /dev/kfd present, or GPU passthrough into containers.
• Prioritize patching shared GPU compute, AI/ML, HPC, CI/CD runner, developer workstation, and multi-user Linux systems before single-user or non-GPU systems.
• Install a vendor-fixed kernel and reboot into it; verify the running kernel version after reboot.
• Until patching is complete, restrict /dev/kfd and /dev/dri/renderD* access to trusted users and trusted workloads only.
• Review container orchestration and runtime policies to ensure untrusted containers are not granted AMD GPU device passthrough.
• Monitor kernel logs for amdkfd-related oops, panic, KASAN, slab out-of-bounds, or general protection fault messages, especially on shared GPU systems.
• Treat unexplained amdkfd kernel crashes from untrusted-user systems as potentially security-relevant and preserve logs, crash dumps, and workload provenance.
• Because current exploitation maturity is none, EPSS is low, and the issue is not KEV-listed, handle as prioritized routine patching unless the environment exposes AMD GPU devices to untrusted users.