CVE-2026-53144

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel AMD Kernel Fusion Driver component, drm/amdkfd. A userspace caller can invoke kfd_ioctl_set_debug_trap() with num_queues greater than zero while providing a NULL queue_array_ptr. The vulnerable get_queue_ids() path returns NULL instead of an error pointer, and callers only check IS_ERR(), allowing execution to continue until q_array_invalidate() dereferences the NULL pointer. The result is a kernel NULL pointer dereference and likely kernel panic, crashing the host.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU/KFD functionality exposed may be crashed by a local user or compromised workload, causing downtime for GPU compute nodes, workstations, CI runners, containers, or shared high-performance computing environments. The risk is primarily availability impact rather than data theft. EPSS is currently low, it is not listed in CISA KEV, and no mature public exploitation is indicated, but local multi-user or GPU-as-a-service environments should prioritize remediation because exploitation can intentionally take systems offline.

How an attack unfolds

An attacker first needs local code execution or the ability to run a process that can access the AMD KFD device interface, typically /dev/kfd. The attacker then opens the KFD device and sends a crafted debug-trap ioctl request where num_queues is non-zero but the queue array pointer is zero or NULL. In vulnerable kernels, get_queue_ids() treats this invalid combination incorrectly by returning NULL instead of an error. The caller does not reject the value because it only checks IS_ERR(), and suspend_queues() subsequently calls q_array_invalidate(), which dereferences the NULL queue ID array while iterating over the supplied non-zero queue count. This triggers a kernel oops or panic, terminating system availability until recovery or reboot.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the amdkfd fix corresponding to upstream commit f165a82cdf503884bb1797771c61b2fcc72113d4 or its backport. Because no exact fixed package versions were provided, track vendor advisories for the deployed distribution and kernel stream, including enterprise, cloud, appliance, and real-time kernel variants. After updating, reboot into the patched kernel and remove or restrict booting into vulnerable kernels. Where immediate patching is not possible, reduce exposure by restricting access to /dev/kfd to trusted users only, removing untrusted users from GPU/render-related groups, disabling GPU passthrough for untrusted workloads, isolating multi-tenant GPU jobs, or disabling/blacklisting the amdkfd driver where AMD KFD functionality is not required. These mitigations reduce exploitability but do not replace patching.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not just that patched packages are installed. Validate with uname -r, package manager inventory, and the relevant distribution security advisory. For source-built kernels, confirm the amdkfd get_queue_ids() logic rejects a NULL user queue array when num_queues is non-zero and returns an error such as -EINVAL rather than NULL. Verify that older vulnerable kernels are not available as the default boot option. Review permissions on /dev/kfd and confirm only trusted principals can access it. Avoid destructive proof-of-concept testing on production systems because a successful test may intentionally panic the kernel; if validation testing is required, perform it only in an isolated lab host or VM with crash recovery enabled.

Typical attack path

1. Obtain local execution on a Linux system using the vulnerable AMD KFD kernel driver path.
2. Confirm access to the KFD device interface, commonly /dev/kfd, directly or through a GPU-enabled workload/container.
3. Open the KFD device from userspace.
4. Issue a crafted kfd_ioctl_set_debug_trap() request with num_queues greater than zero and queue_array_ptr set to NULL or 0.
5. Trigger the vulnerable get_queue_ids() handling path, causing a NULL return that is not rejected by IS_ERR().
6. Force q_array_invalidate() to dereference the NULL queue array and crash the kernel.
7. Rely on the resulting kernel panic or oops to deny service until the system is rebooted or recovered.

How to detect it

This vulnerability causes a kernel crash rather than a quiet post-exploitation artifact, so detection should focus on evidence of unexpected panics, oops events, vmcores, and reboot sequences involving the AMD KFD driver. Review kernel logs from the previous boot using journalctl -k -b -1, persistent syslog, dmesg archives, crash dump metadata, kdump/vmcore analysis, and hardware or platform event logs for NULL pointer dereferences with stack frames such as get_queue_ids(), suspend_queues(), q_array_invalidate(), or kfd_ioctl_set_debug_trap(). Correlate crashes with local process activity that opened /dev/kfd, GPU job scheduler records, container runtime logs, auditd records, eBPF syscall/ioctl telemetry, and user login/session history. Look for repeated crashes shortly after GPU-enabled jobs start or after untrusted workloads receive access to /dev/kfd. Because the issue is not known to be KEV-listed and exploit maturity is reported as none, treat detections as suspicious availability events requiring correlation rather than definitive malicious compromise.

• /dev/kfd
• amdkfd
• drm/amdkfd
• kfd_ioctl_set_debug_trap
• get_queue_ids
• suspend_queues
• q_array_invalidate
• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• queue_array_ptr
• num_queues
• RIP: 0010:q_array_invalidate
• RIP: 0010:get_queue_ids
• RIP: 0010:suspend_queues
• RIP: 0010:kfd_ioctl_set_debug_trap

What your security team should do

• Prioritize patching Linux systems that expose AMD KFD/ROCm/GPU compute functionality to local users, containers, CI jobs, research workloads, or other semi-trusted code.
• Inventory hosts with /dev/kfd present and AMD GPU workloads enabled; focus first on shared or multi-tenant environments.
• Apply vendor kernel updates containing the amdkfd NULL dereference fix and reboot into the patched kernel.
• Restrict /dev/kfd access to trusted users and workloads until patching is complete.
• Review recent kernel panic, oops, crash dump, and reboot events for amdkfd-related stack traces that may indicate exploitation or testing.
• Ensure monitoring alerts on unexpected GPU compute node reboots, kernel panics, and repeated crashes involving amdkfd functions.
• Remove vulnerable kernels from boot menus or enforce boot policy so systems cannot roll back to affected builds.
• If using containers or job schedulers with GPU access, ensure untrusted jobs cannot access /dev/kfd unless explicitly required and isolated.