CVE-2026-68275 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO
The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it.
amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference.
This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO.
Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released.
(cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability exists within the AMDGPU driver implementation in the Linux kernel's direct rendering manager subsystem, specifically affecting the drm/amdgpu module. This issue manifests when processing the AMDGPU_GEM_OP_GET_MAPPING_INFO operation through the amdgpu_gem_op_ioctl() function. The flaw occurs during buffer object virtual memory management operations where the system fails to validate the return value from the amdgpu_vm_bo_find() lookup function before proceeding with subsequent operations.
The technical root cause stems from improper error handling in the AMDGPU kernel driver code. When amdgpu_vm_bo_find() is invoked to locate a buffer object virtual address entry within a specific virtual memory context, it legitimately returns NULL for buffer objects that have never been mapped into that particular VM. This is a normal operational condition rather than an error state requiring termination. However, the calling code does not perform this validation check before passing the potentially NULL pointer to amdgpu_vm_bo_va_for_each_valid_mapping() macro expansion.
The subsequent dereference operation in amdgpu_vm_bo_va_for_each_valid_mapping() which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) directly accesses memory locations through the NULL bo_va pointer, resulting in a kernel space NULL pointer dereference exception. This condition causes immediate system termination through a kernel oops or panic, effectively creating a denial of service vulnerability that can be triggered by any process possessing render group privileges.
This vulnerability aligns with CWE-476 which describes NULL Pointer Dereference, and represents a classic improper error handling scenario where the driver fails to account for legitimate null return values from lookup functions. The attack vector requires minimal privileges as only render group access is needed to execute the vulnerable ioctl command, making this particularly concerning for multi-user systems where unprivileged processes might have access to GPU rendering capabilities.
The fix implements proper error checking by returning -ENOENT when no valid bo_va entry is found, which causes immediate cleanup of the drm_exec context and GEM object reference through the out_exec jump label. This approach follows established kernel programming practices for handling lookup failures and ensures proper resource management while preventing the subsequent NULL pointer dereference that would otherwise crash the kernel.
From an operational security perspective, this vulnerability represents a critical risk in production environments where GPU access is granted to untrusted users or processes. The denial of service impact extends beyond simple process termination as it can affect entire graphics subsystems and potentially compromise system stability. The ATT&CK framework categorizes this under privilege escalation and denial of service tactics, as it allows an attacker with render group access to cause system-wide instability through kernel memory corruption.
The fix demonstrates proper defensive programming principles by validating all function return values before use and implementing appropriate error propagation mechanisms. This vulnerability illustrates the importance of thorough input validation in kernel drivers where untrusted inputs can flow through complex call chains to ultimately affect kernel memory safety. The solution maintains backward compatibility while strengthening system resilience against malformed ioctl requests that attempt to query mapping information for unmapped buffer objects, which is a legitimate operation that should return appropriate error codes rather than crash the system.