CVE-2026-46215: drm: Set old handle to NULL before prime swap in change_handle
In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths
HarborGuard Analysis
HarborGuard analysisSynopsis
A use-after-free vulnerability exists in the Linux kernel's Direct Rendering Manager (DRM) subsystem, specifically in the change_handle code path for GEM (Graphics Execution Manager) buffer objects. A local attacker with a low-privilege account can exploit a race condition between change_handle and gem_close ioctls to free a GEM object and then dereference the dangling handle, achieving arbitrary read, write, and code execution in kernel context. Patched-image rebuilds at the fix commits (including kernel 6.18.32) are available on HarborGuard for affected environments.
HarborGuard Coverage
Detection is available across every HarborGuard environment; the CVE is ingested from upstream feeds within minutes of publication and matched against customer images, including custom-built images incorporating affected kernel versions. Any image in a customer registry or CI/CD pipeline that packages a Linux kernel in the affected range is flagged automatically.
AvailableHarborGuard scores this CVE at 7.8 HIGH using the published CVSS v3.1 vector and can weight that score against each environment's compliance policy to determine breach-of-policy status. Findings are routed to the appropriate team inbox within each customer organization based on image ownership and policy configuration.
AvailableA patched-image rebuild targeting the fix commits (kernel 6.18.32 or the corresponding stable-tree commits) becomes available on HarborGuard once a customer's base image incorporates the upstream fix. For customers who opt into auto-remediation, HarborGuard performs the rebuild, runs a regression test suite, and opens a pull request against affected workloads; for high-severity issues, median time from CVE publication to merged patch PR is around 90 minutes in environments with auto-remediation enabled.
AvailableExploit Conditions
- Network reachabilityNot required
The attacker needs an existing shell or process on the host; no network access to the target is required.
- AuthenticationRequired
Any low-privilege local account is sufficient; the attacker does not need administrative or root credentials to trigger the race condition.
- Victim interactionNot required
No interaction from another user or process is required; the attacker races their own ioctls against the kernel's internal handle management.
- Attack complexityDetail
The exploit relies on a race condition between concurrent ioctls, but the CVSS rating of AC:L indicates the timing window is reliable enough to be considered condition-free for scoring purposes.
Blast Radius
- A successful attacker reads arbitrary kernel memory, including credentials, session tokens, and data from other processes.
- The attacker writes to arbitrary kernel memory, allowing modification of security-critical kernel structures such as credentials or privilege levels.
- The attacker can achieve arbitrary code execution in kernel context, effectively taking full control of the host.
- Any containers or workloads sharing the affected kernel are also exposed, since kernel memory is shared across the host's process namespace.
How HarborGuard Handles This
Available on HarborGuard: detection fires within minutes of CVE publication for any image packaging a Linux kernel version between commit 53096728b891 and the respective fix commits across the affected stable branches, including 6.18 kernels prior to 6.18.32. Where compliance policy permits, HarborGuard can initiate a patched-image rebuild once the customer's base image is updated to an unaffected kernel version, then run a regression test pass and open a pull request against affected workloads. For customers who opt into auto-remediation, the median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes. Until a base image update is available in a given environment, consider applying kernel-level compensating controls: restrict unprivileged access to DRM device nodes via device cgroup rules, limit the set of allowed ioctls through a seccomp filter, or isolate GPU-dependent workloads from untrusted users at the namespace level. HarborGuard re-checks advisory status each ingest cycle and will surface rebuild availability as soon as an updated base image is detected.
Metrics
- CVSS v3.1
- 7.8
- Severity
- HIGH
- Fixed in
- 0
- Affected Products
- 2
Fix available
- Linux / Linux< 672464dd53231509c9c771110798c56d4660e19e (from 53096728b8910c6916ecc6c46a5abc5c678b58d9) · < 61bd96d3e5472c253f9c1ab77608f0c8aaa9d025 (from 53096728b8910c6916ecc6c46a5abc5c678b58d9) · < 5e28b7b94408897e41c63477aabc9e1db439bc8c (from 53096728b8910c6916ecc6c46a5abc5c678b58d9)
- Linux / Linux6.18Fixed in 0, 6.18.32, 7.0.9, 7.1-rc3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H