CVE-2026-53145 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Try to fix change_handle ioctl, attempt 4
[airlied: just added some comments on how to reenable]
On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far:
5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong:
- There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong.
- dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix.
We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out:
- Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing.
- Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there.
- This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia.
- Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit.
- While at it, also replace the 7 space indent with 1 tab.
And finally, because I flat out don't trust my abilities here at all anymore:
- Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus.
v2:
Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky.
Also add the Fixes: line for the original ioctl, I forgot that too.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/25/2026
This vulnerability resides within the linux kernel's direct rendering manager gem subsystem and specifically addresses a race condition in the change_handle ioctl implementation. The issue stems from confusion around variable naming and improper handling of idr (integer descriptor reference) operations during concurrent access scenarios. The original fix attempt 5e28b7b94408 attempted to address a race between gem_close and gem_change_handle ioctls but introduced incorrect logic by confusing the local handle variable with the new handle, leading to improper two-stage idr slot manipulation. Subsequent attempts 7164d78559b0 and dc366607c41c further compounded the problem through inconsistent application of fixes and missing error handling, creating multiple flawed code paths that could result in system instability or potential privilege escalation.
The technical flaw manifests as a race condition involving concurrent gem_close and gem_change_handle operations where improper idr slot management can lead to dangling references or object corruption. The confusion between local variable handle and the actual new handle creates situations where the two-stage idr_replace operation targets the wrong identifier, potentially causing memory management issues in the graphics driver's object handling system. This vulnerability directly relates to common weakness enumeration 362 which describes race conditions in concurrent programming, and aligns with attack technique T1068 which involves exploiting local privilege escalation through kernel vulnerabilities.
The operational impact of this vulnerability could allow malicious users to exploit the race condition to cause system crashes, memory corruption, or potentially achieve privilege escalation within the graphics subsystem. The improper error handling and inconsistent idr management creates scenarios where concurrent operations might result in invalid memory references or object state corruption that could be leveraged for more serious security implications. This affects systems using drm/gem subsystems with concurrent access patterns to graphics objects through ioctl interfaces, particularly impacting graphics-intensive applications and server environments.
Mitigation strategies should focus on implementing proper error checking for idr_replace operations using IS_ERR_OR_NULL validation as demonstrated in the corrected implementation. The fix involves renaming confusing variables to clearly distinguish between old and new handles, merging object lookup with idr_replace operations to avoid confusion, and applying established patterns from other ioctls such as create_tail's two-stage approach to prevent concurrent gem_close operations from stealing references. Additionally, disabling the ioctl until comprehensive testing and consensus are achieved provides a safer interim measure while more thorough analysis is conducted. The fix also includes correcting error paths to ensure proper cleanup and maintain consistency with existing kernel patterns, addressing both immediate operational concerns and long-term code maintainability issues.