CVE-2026-63885 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: fix race between change_handle and handle_delete
drm_gem_change_handle_ioctl leaves the old handle live in the IDR during the window between spin_unlock(table_lock) and the final spin_lock(table_lock). A concurrent drm_gem_handle_delete on the old handle succeeds in this window, decrements handle_count to 0, and frees the GEM object while the new handle's IDR entry still references it.
NULL the old handle's IDR entry before dropping table_lock so that any concurrent GEM_CLOSE on the old handle sees NULL and returns -EINVAL. Restore the old entry on the prime-bookkeeping error path.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's Direct Rendering Manager graphics subsystem, specifically in the Generic Entry Management component that handles graphics memory objects. The issue manifests as a race condition during the process of changing GEM object handles, where concurrent operations can lead to inconsistent state management and potential memory corruption. The vulnerability stems from improper synchronization between handle modification and deletion operations within the kernel's graphics memory management system.
The technical flaw occurs in the drm_gem_change_handle_ioctl function where the system unlocks the table lock before properly nullifying the old handle's IDR entry. During this brief window between spin_unlock(table_lock) and the subsequent spin_lock(table_lock), a concurrent drm_gem_handle_delete operation can successfully process the old handle, decrementing the handle_count to zero and freeing the underlying GEM object while a new handle's IDR entry still maintains a reference to it. This creates a dangling pointer scenario where the new handle points to memory that has already been freed, potentially leading to use-after-free conditions and system instability.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation attacks within the graphics subsystem. An attacker could exploit this race condition to manipulate memory layout and potentially execute arbitrary code with kernel privileges. The vulnerability affects systems running Linux kernels that utilize the DRM subsystem for graphics processing, particularly those handling concurrent GEM object operations. This represents a critical security concern as it allows for potential exploitation of kernel memory management functions without requiring elevated privileges.
The mitigation strategy involves modifying the handle change process to NULL the old handle's IDR entry before releasing the table lock, ensuring that any concurrent GEM_CLOSE operations on the old handle will immediately detect the NULL reference and return -EINVAL instead of proceeding with invalid memory operations. Additionally, proper error handling must be implemented to restore the old entry during prime-bookkeeping error paths to maintain system consistency. This fix aligns with CWE-362 which addresses race conditions in concurrent systems and follows ATT&CK technique T1068 for privilege escalation through kernel vulnerabilities. The solution requires careful synchronization between memory management operations and proper handling of reference counting to prevent inconsistent state transitions in the graphics memory subsystem.