CVE-2026-63885 Overview
CVE-2026-63885 is a race condition in the Linux kernel's Direct Rendering Manager (DRM) Graphics Execution Manager (GEM) subsystem. The flaw exists in drm_gem_change_handle_ioctl, which leaves the old handle live in the ID Radix tree (IDR) between spin_unlock(table_lock) and the final spin_lock(table_lock). A concurrent drm_gem_handle_delete call on the old handle can succeed during this window, decrement handle_count to zero, and free the GEM object while the new handle's IDR entry still references it. This creates a use-after-free condition affecting local users with access to DRM device nodes.
Critical Impact
Local attackers with access to DRM devices can trigger a use-after-free in kernel memory, enabling privilege escalation, information disclosure, or system crash.
Affected Products
- Linux kernel versions containing the drm_gem_change_handle_ioctl implementation prior to the fix
- Distributions shipping vulnerable stable kernel branches
- Systems exposing DRM device nodes to unprivileged users
Discovery Timeline
- 2026-07-19 - CVE-2026-63885 published to the National Vulnerability Database (NVD)
- 2026-07-20 - Last updated in NVD database
Technical Details for CVE-2026-63885
Vulnerability Analysis
The vulnerability is a Time-of-Check Time-of-Use (TOCTOU) race condition in the DRM GEM handle-change ioctl path. The GEM subsystem tracks buffer objects through per-file handle tables backed by an IDR, protected by table_lock. During drm_gem_change_handle_ioctl, the function releases table_lock while the old handle still points to the target GEM object. A second thread invoking GEM_CLOSE on the old handle observes a valid entry, calls drm_gem_handle_delete, decrements handle_count to zero, and releases the underlying object. When the original ioctl reacquires the lock and completes, the new handle references freed memory.
Root Cause
The root cause is improper synchronization of IDR state across a critical section boundary. The old handle's IDR entry must not remain visible to concurrent lookups once the code has committed to reassigning ownership. Leaving the entry populated after unlocking table_lock violates the invariant that handle lookups return objects with a valid reference count.
Attack Vector
Exploitation requires local access and the ability to open a DRM device node such as /dev/dri/card0 or /dev/dri/renderD128. An attacker races two threads: one issuing the DRM_IOCTL_GEM_CHANGE_HANDLE ioctl and another issuing DRM_IOCTL_GEM_CLOSE on the same source handle. Winning the race frees the GEM object while a dangling IDR entry remains, allowing subsequent operations on the new handle to touch freed kernel memory. Successful exploitation can lead to kernel memory corruption, arbitrary code execution in kernel context, or denial of service.
No verified proof-of-concept code is publicly available. See the upstream fix commits for technical details: Linux Kernel Commit 0dfa42cf, Linux Kernel Commit 7164d785, and Linux Kernel Commit cde2c925.
Detection Methods for CVE-2026-63885
Indicators of Compromise
- Kernel oops or panic messages referencing drm_gem_object_free, drm_gem_handle_delete, or drm_gem_change_handle_ioctl in dmesg output
- KASAN or SLUB debug reports flagging use-after-free in the DRM GEM object slab cache
- Unexpected -EINVAL returns from GEM_CLOSE immediately followed by handle-change activity on the same file descriptor
Detection Strategies
- Enable CONFIG_KASAN on test kernels to surface use-after-free accesses in the DRM GEM path
- Audit process telemetry for unprivileged processes issuing high-frequency DRM_IOCTL_GEM_CHANGE_HANDLE and DRM_IOCTL_GEM_CLOSE calls against the same handle
- Correlate kernel crash signatures with local user activity to identify race-condition exploitation attempts
Monitoring Recommendations
- Forward kernel ring buffer logs to a centralized logging platform and alert on GEM-related oops signatures
- Monitor for repeated segmentation faults or kernel panics originating from graphics or compute workloads run by non-root users
- Track ioctl usage patterns on /dev/dri/* nodes, especially from processes not associated with legitimate graphics stacks
How to Mitigate CVE-2026-63885
Immediate Actions Required
- Apply the upstream stable kernel patches referenced in the commit links as soon as vendor builds are available
- Restrict access to /dev/dri/* device nodes to trusted users and graphics group members only
- Prioritize patching multi-tenant systems, container hosts, and shared workstations where local users can invoke DRM ioctls
Patch Information
The fix NULLs the old handle's IDR entry before dropping table_lock, ensuring any concurrent GEM_CLOSE on the old handle observes a NULL entry and returns -EINVAL. The old entry is restored on the prime-bookkeeping error path. Patches are available in the mainline and stable branches via commits 0dfa42cf, 7164d785, and cde2c925.
Workarounds
- Tighten permissions on DRM device nodes using udev rules so only members of the video or render group can open them
- Disable or block the DRM_IOCTL_GEM_CHANGE_HANDLE ioctl through seccomp filters for untrusted workloads and container runtimes
- Deploy Linux Security Module (LSM) policies such as SELinux or AppArmor to confine processes that do not require direct GPU access
# Example udev rule to restrict DRM device access to the video group
cat > /etc/udev/rules.d/99-drm-restrict.rules <<'EOF'
SUBSYSTEM=="drm", KERNEL=="card*", MODE="0660", GROUP="video"
SUBSYSTEM=="drm", KERNEL=="renderD*", MODE="0660", GROUP="render"
EOF
udevadm control --reload-rules && udevadm trigger
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
