CVE-2026-46215

What it actually does

This is a local Linux kernel use-after-free race condition in the DRM/GEM handle management path. A privileged-enough local user that can access DRM device nodes can race handle-changing PRIME operations against GEM handle close operations, temporarily creating inconsistent IDR handle state where one object can be reachable through multiple handles. If a concurrent close frees the underlying object while another dangling handle remains, later dereference can trigger memory corruption. Practical outcomes may include kernel crash, denial of service, information disclosure, or local privilege escalation depending on allocator behavior, kernel hardening, and exploit reliability.

Why it matters to the business

Successful exploitation can allow a local user or compromised workload with access to GPU/DRM devices to destabilize the host or potentially gain elevated privileges on the system. This is most relevant for Linux desktops, GPU-enabled servers, multi-user systems, CI/build workers, container hosts exposing /dev/dri, and compute environments that pass GPU devices into untrusted workloads. The issue is not currently listed in CISA KEV, is not marked as ransomware-associated, and has a low EPSS score, so urgency is lower than for actively exploited remote vulnerabilities; however, kernel local privilege escalation bugs should still be prioritized where untrusted users or containers can access DRM devices.

How an attack unfolds

An attacker first needs local code execution and permission to open a DRM device such as a GPU card or render node. They then create GEM/PRIME handles and repeatedly invoke the vulnerable handle-change path while racing it from another thread or process with GEM close operations. During the race window, the kernel can briefly maintain inconsistent handle mappings to the same object. If the close operation frees the object while a second handle remains visible, the attacker attempts to trigger a later dereference of the stale handle. A simple exploit may only crash the kernel, while a more advanced exploit would try to shape kernel heap allocations so the freed object is replaced with attacker-influenced data, potentially enabling arbitrary kernel memory access or privilege escalation.

How to fix it

Apply the kernel update from the Linux distribution or vendor that includes the DRM fix for the handle race in change_handle. No exact fixed package versions were provided in the input, so track the relevant vendor advisories for the deployed kernel branches and upgrade to the first fixed kernel available for each supported distribution. Reboot into the patched kernel and remove or de-prioritize older vulnerable kernels where operationally feasible. Until patched, reduce exposure by restricting access to /dev/dri/card* and /dev/dri/renderD* to trusted users only, avoiding GPU device passthrough into untrusted containers or VMs, disabling unnecessary DRM/GPU device exposure on servers, and applying standard kernel hardening features such as user namespace restrictions, container confinement, SELinux/AppArmor policy, and seccomp profiles where compatible.

How to confirm the fix worked

Confirm the running kernel version after reboot with uname -a and compare it to the distribution advisory that contains the DRM/GEM race fix. Verify that package inventory and vulnerability scanners no longer report the affected Linux kernel build. Confirm that untrusted users and workloads cannot open /dev/dri/card* or /dev/dri/renderD* unless required. On container platforms, inspect device passthrough configuration and ensure GPU devices are not exposed to workloads that do not need them. Where source or vendor changelog validation is used, look for the fix described as setting the old DRM handle to NULL before PRIME swap in change_handle or equivalent DRM/GEM handle race remediation.

Typical attack path

1. Gain local code execution as a low-privileged user or inside a workload that has access to Linux DRM/GPU device nodes.
2. Open an accessible DRM device, commonly under /dev/dri/.
3. Create GEM/PRIME buffer handles and prepare concurrent operations against the same object.
4. Race the vulnerable handle-change ioctl path against GEM handle close operations.
5. Trigger dereference of a stale handle after the underlying object has been freed.
6. Leverage the use-after-free to crash the kernel or, with additional heap manipulation, attempt local privilege escalation.

How to detect it

Look for evidence of local exploitation attempts in kernel logs, audit logs, EDR telemetry, and crash dumps. Relevant log sources include journald, dmesg, /var/log/kern.log, /var/log/messages, auditd syscall/file access records, container runtime logs, GPU scheduler logs, and kernel crash dump facilities such as kdump or apport. Search for kernel warnings, Oops reports, KASAN or KFENCE findings, general protection faults, NULL pointer or use-after-free reports, and stack traces that reference DRM, GEM, PRIME, IDR, handle close, or GPU driver code. Also review process telemetry for untrusted users or containers repeatedly opening /dev/dri/card* or /dev/dri/renderD* and generating high-volume DRM ioctls shortly before a crash. Absence of these artifacts does not prove non-exploitation, because a successful local privilege escalation may leave limited traces unless kernel debugging, auditd, or EDR telemetry was enabled.

• KASAN: use-after-free
• BUG: KASAN
• KFENCE: use-after-free
• general protection fault
• kernel BUG
• Oops:
• drm_gem
• gem_close
• drm_prime
• change_handle
• drm_gem_handle_create_tail
• drm_gem_handle_delete
• drm_gem_handle_create
• /dev/dri/card
• /dev/dri/renderD
• /dev/dri/controlD
• renderD128
• card0
• prime_fd_to_handle
• prime_handle_to_fd

What your security team should do

• Prioritize patching Linux systems where untrusted local users, shared workloads, containers, or GPU-enabled jobs can access /dev/dri devices.
• Inventory hosts exposing DRM/GPU device nodes, especially multi-user servers, desktop fleets, VDI, CI workers, container hosts, and GPU compute nodes.
• Restrict membership in groups that grant DRM/GPU access, commonly video or render, to trusted accounts only.
• Review container, Kubernetes, and virtualization configurations for unnecessary /dev/dri passthrough.
• Monitor kernel logs for KASAN, use-after-free, general protection fault, BUG, or Oops events involving DRM, GEM, PRIME, or GPU drivers.
• Treat unexplained kernel crashes on GPU-enabled hosts as potentially security-relevant until patched and reviewed.
• Because this is not KEV-listed and has low EPSS, schedule broad fleet remediation through the normal kernel patch cycle, but accelerate for shared or untrusted local-access environments.