CVE-2026-63882

What it actually does

This is a Linux kernel denial-of-service flaw in the AMD Kernel Fusion Driver component, specifically in the amdkfd SVM ioctl handling path. If a process invokes the SVM ioctl path without first acquiring the required VM state through kfd_ioctl_acquire_vm, the kernel may dereference a NULL process_info pointer in svm_range_set_attr. The likely result is a kernel oops or crash affecting system stability. Based on the available description, this is a local flaw requiring the ability to interact with the AMD GPU/KFD device interface; there is no indication of remote code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU/KFD functionality exposed may be vulnerable to local crashes caused by malformed or out-of-sequence GPU ioctl calls. In practical terms, a local user, compromised workload, or container with access to the relevant GPU device could disrupt compute nodes, desktops, VDI hosts, or GPU-accelerated workloads. The current EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad opportunistic exploitation is not currently indicated; however, availability impact can still be significant for shared GPU infrastructure.

How an attack unfolds

An attacker first needs local execution or equivalent access to a context that can open and issue ioctls to the AMD KFD/DRM GPU device interface. Instead of following the expected initialization sequence, the attacker invokes the KFD SVM ioctl path before calling the VM acquisition ioctl. Because the kernel code assumes process_info has been initialized, svm_range_set_attr may dereference a NULL pointer. This causes a kernel fault, which may panic or destabilize the host depending on kernel configuration and error handling. Repeating the action can be used to produce a reliable local denial of service on vulnerable systems.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the amdkfd NULL pointer bug in svm_range_set_attr. The fix is associated with upstream commit 83a26c812e0529eb040d31a76f73e33e637243d4 and should be obtained through the appropriate distribution kernel package, long-term-stable kernel release, or vendor kernel advisory. Because no fixed package versions were provided, track the kernel version and vendor errata for your distribution. As interim mitigation, restrict access to AMD GPU/KFD device nodes to trusted users and workloads only, remove unnecessary GPU device passthrough from containers or virtual machines, and consider disabling or unloading AMD KFD/AMDGPU functionality on systems that do not require it.

How to confirm the fix worked

Confirm the running kernel includes the vendor backport or upstream fix for the amdkfd svm_range_set_attr NULL pointer handling issue. Validate by checking distribution kernel changelogs, package errata, or source patches for the commit or equivalent NULL-check fix. Inventory systems with AMD GPUs and loaded amdgpu/amdkfd functionality, then verify they are running a remediated kernel after reboot. Also confirm that untrusted users and containers cannot access KFD/DRM device nodes unless explicitly required. Avoid using crash-trigger proof-of-concept testing on production systems because successful validation may intentionally crash the host.

Typical attack path

1. Gain local code execution on a Linux system with an affected kernel and AMD KFD/DRM support enabled.
2. Confirm access to AMD GPU/KFD device nodes, such as DRM render nodes or KFD interfaces, depending on distribution configuration.
3. Open the relevant GPU device from user space.
4. Issue the SVM ioctl path without first invoking the expected VM acquisition ioctl sequence.
5. Trigger the NULL pointer dereference in svm_range_set_attr.
6. Cause a kernel oops, crash, panic, or GPU/host instability resulting in denial of service.

How to detect it

To assess whether this was already exploited or triggered, review kernel and system logs from GPU-enabled Linux hosts for NULL pointer dereferences, kernel oopses, panics, or stack traces involving amdkfd, kfd_ioctl_svm, kfd_ioctl_acquire_vm, or svm_range_set_attr. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore metadata, and EDR telemetry that captures process-to-device access. Correlate crash times with local user sessions, container starts, batch jobs, GPU workloads, and process executions that accessed /dev/kfd or DRM render nodes. Evidence is likely to be host-local and availability-focused; there are no known network indicators from the provided intelligence. If repeated oops events occur shortly after untrusted workloads access AMD GPU devices, treat that as suspicious even if the activity could also be caused by malformed or buggy GPU software.

• svm_range_set_attr
• kfd_ioctl_svm
• kfd_ioctl_acquire_vm
• amdkfd
• amdgpu
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• /dev/kfd
• /dev/dri/renderD
• 83a26c812e0529eb040d31a76f73e33e637243d4

What your security team should do

• Prioritize patching Linux systems that expose AMD GPU/KFD devices to untrusted local users, shared tenants, containers, research workloads, CI jobs, VDI users, or GPU compute workloads.
• Obtain fixed kernels from the relevant Linux distribution or hardware platform vendor and schedule reboots to ensure the patched kernel is actually running.
• Restrict permissions on GPU device nodes and remove unnecessary GPU passthrough from containers, virtual machines, and untrusted workloads until patching is complete.
• Review kernel logs for recent amdkfd, kfd_ioctl_svm, svm_range_set_attr, NULL pointer dereference, oops, or panic messages that may indicate attempted or accidental triggering.
• Add monitoring for repeated local process crashes followed by kernel oops events on GPU-enabled Linux systems.
• Because EPSS is low, there is no KEV listing, and exploit maturity is reported as none, treat this as a targeted local availability risk rather than an internet-scale emergency, while still prioritizing high-value shared GPU infrastructure.