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
Security readout for executives and security teams
Plain-English summary
A flaw in Linux graphics memory handling can let a low-privileged local process trigger a race that leaves a stale object reference. Successful exploitation could compromise system confidentiality, integrity, and availability. The issue is local rather than remotely reachable, and the supplied evidence does not establish active exploitation.
Executive priority
Treat this as an accelerated patching priority for affected multi-user systems and endpoints that execute untrusted local code. It does not warrant an internet-perimeter emergency based on the supplied evidence, but the potential for full confidentiality, integrity, and availability impact makes prolonged exposure undesirable.
Technical view
The DRM change_handle ioctl could temporarily map one object through two IDR handles. A concurrent gem_close could free the object while leaving a dangling handle, enabling a use-after-free. The cited fix replaces the old handle with NULL before prime operations and closes it only after successful completion.
Likely exposure
Exposure is most likely on Linux systems running an affected kernel where low-privileged local code can reach the relevant DRM/GEM ioctl path. The bundle names 6.18, 6.18.32, 7.0.9, and 7.1, but its version representation is ambiguous; confirm vendor backport status rather than relying solely on version strings.
Exploitation context
CVSS 3.1 rates this 7.8 with local access, low complexity, low privileges, and no user interaction. A GitHub repository is tagged as an exploit reference, but that alone does not validate a working exploit. The CVE is not listed as KEV, and no supplied source confirms active exploitation.
Researcher notes
The key primitive is a race-driven DRM use-after-free involving handle replacement and concurrent closure. Assessment should focus on reachability of change_handle and vendor backport provenance without attempting exploitation. The bundle includes a repeated commit identifier, an unexplained version 0 entry, and isolated release values, so affected ranges should not be inferred.
Mitigation direction
Upgrade to a vendor-supported kernel containing a cited stable fix or equivalent backport.
Reboot affected systems into the updated kernel after installation.
If patching is delayed, consult the Linux distribution vendor for supported temporary mitigations.
Limit untrusted local access on affected systems until remediation is complete.
Validation and detection
Inventory exact running kernel builds across Linux systems.
Confirm each deployed build contains a cited fix or an equivalent vendor backport.
Verify systems are running the updated kernel after reboot.
Run approved graphics and DRM regression testing after remediation.
Review vendor advisories because the supplied affected-version data is ambiguous.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46215 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
5Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.