CVE-2026-31765

What it actually does

This is a local denial-of-service flaw in the Linux kernel AMDGPU/KFD code path on systems using 64 KB kernel pages. The driver reserved too little GPU virtual address space for the AMDGPU trap area while allocating a larger CWSR TBA/TMA region, causing an inconsistent memory reservation/allocation state. When a local user triggers KFD GPU VM initialization through ROCm-related operations, the kernel can hit a NULL pointer dereference and panic or oops, resulting in loss of system availability. The issue does not indicate remote code execution, privilege escalation, or data disclosure based on the provided details.

Why it matters to the business

Affected Linux systems with AMD GPUs, especially ROCm, HPC, AI/ML, or accelerated compute hosts using 64 KB page-size kernels, may crash when ordinary GPU discovery or compute workloads run. This can interrupt jobs, require reboots, cause workload loss, and reduce reliability of shared compute infrastructure. The urgency is moderate: CVSS indicates high availability impact from a local attacker or user process, while EPSS is very low, stable over 30 days, not listed in CISA KEV, not associated with ransomware, and has no known exploit maturity in the provided data.

How an attack unfolds

An attacker must already have local access to an affected Linux system and enough permissions to interact with AMD GPU/KFD interfaces, commonly through membership in GPU-related groups or access to ROCm tooling. On a vulnerable 64 KB page-size kernel with the AMDGPU driver loaded, the attacker runs a program or tool such as ROCm discovery or compute initialization that invokes KFD ioctls and triggers GPU VM setup. During trap/TBA/TMA allocation, the driver’s reserved virtual address space is smaller than the allocation it attempts to manage. This mismatch leads the kernel into an invalid memory access, producing a NULL pointer dereference in the AMDGPU/KFD call path and potentially crashing the host. The likely attacker objective is disruption rather than persistence or data theft.

How to fix it

Upgrade to a Linux kernel build from the operating system or distribution vendor that includes the AMDGPU/KFD fix changing the reserved trap sizing behavior, including the upstream change associated with commit 31b8de5e55666f26ea7ece5f412b83eab3f56dbb or an equivalent backport. No exact fixed package versions were provided, so track vendor advisories for the affected kernel stream and install the first kernel release that explicitly references this CVE or the AMDGPU reserved trap size fix. Where immediate patching is not possible, reduce exposure by restricting local access to GPU device nodes, limiting membership in video/render/ROCm-related groups, avoiding untrusted multi-user GPU workloads, disabling or blacklisting the amdgpu/KFD functionality on systems that do not need it, or scheduling affected GPU workloads on patched kernels only. Reboot into the updated kernel after installation; updating packages without booting the fixed kernel is insufficient.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is patched. Validate through vendor package metadata, changelogs, or source/backport review that the AMDGPU/KFD fix for the reserved trap size mismatch is present. On source-based or internally built kernels, verify that AMDGPU_VA_RESERVED_TRAP_SIZE and KFD_CWSR_TBA_TMA_SIZE behavior matches the corrected implementation and that allocation size cannot exceed the reserved trap address area on 64 KB page-size systems. Confirm the host page size and exposure by checking kernel configuration and runtime page size, AMDGPU module loading, AMD GPU presence, and access to /dev/kfd or /dev/dri/renderD*. After patching and rebooting, run standard ROCm validation such as rocminfo and representative GPU workloads on a non-production test host and confirm no kernel oops, NULL pointer dereference, or amdgpu/KFD crash messages appear in dmesg or journal logs.

Typical attack path

1. Obtain local shell or local code execution on a Linux host with an affected kernel, AMDGPU driver, AMD GPU hardware, and 64 KB page-size configuration.
2. Confirm access to AMD GPU device nodes such as /dev/kfd or /dev/dri/renderD* directly or through GPU/ROCm group membership.
3. Run ROCm-related discovery, test, or custom code that initializes KFD GPU VM state, such as functionality similar to rocminfo or RCCL tests.
4. Trigger the vulnerable KFD ioctl path during GPU VM acquisition and CWSR trap/TBA/TMA setup.
5. Cause a kernel NULL pointer dereference or oops in the amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu / kfd_ioctl_acquire_vm path, leading to system instability or crash.

How to detect it

Look for evidence of prior triggering in kernel and system logs rather than network telemetry, because exploitation is local. Primary sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump systems, kdump/vmcore records, workload scheduler logs, ROCm application logs, auditd records for GPU device access, and process accounting. Search for kernel oops or panic messages containing AMDGPU/KFD functions, NULL pointer dereferences at address 0x00000002, and processes such as rocminfo or RCCL tests immediately before the crash. Correlate timestamps with users opening /dev/kfd or /dev/dri/renderD* and with GPU jobs launched on shared compute systems. Because the vulnerability causes availability failure, indicators are likely crash traces, reboot events, failed GPU jobs, and kernel stack frames rather than durable malware artifacts. There are no known threat actors, KEV activity, ransomware use, or public exploit maturity in the provided data, so detections should focus on anomalous local triggering and repeated crash attempts.

• Kernel attempted to read user page (2) - exploit attempt?
• BUG: Kernel NULL pointer dereference on read at 0x00000002
• Comm: rocminfo
• PAGE_SIZE=64K
• amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu
• kfd_process_alloc_gpuvm
• kfd_process_device_init_cwsr_dgpu
• kfd_process_device_init_vm
• kfd_ioctl_acquire_vm
• kfd_ioctl
• __mutex_add_waiter+0x24/0xc0
• /dev/kfd
• /dev/dri/renderD

What your security team should do

• Prioritize patching shared AMD GPU compute systems, ROCm hosts, HPC clusters, AI/ML worker nodes, and any multi-user Linux servers using 64 KB page-size kernels.
• Inventory systems with AMD GPUs and loaded amdgpu/KFD components, especially hosts exposing /dev/kfd or /dev/dri/renderD* to non-administrative users or containers.
• Restrict GPU device-node access to trusted users and workloads until patched; remove unnecessary users from render, video, or ROCm-related access groups.
• Review kernel logs for prior oops or panic events matching the AMDGPU/KFD stack trace to identify possible prior exploitation or accidental triggering.
• Coordinate patching with workload owners because remediation requires rebooting into a fixed kernel.
• If GPU acceleration is not required on a vulnerable host, disable the amdgpu module or KFD access as a temporary mitigation.
• Monitor vendor advisories for exact fixed kernel package versions because none were provided in the input data.