Description
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.
Published: 2026-06-25
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability stems from a race condition between the gem_close and gem_change_handle ioctl calls in the Linux kernel’s DRM subsystem. An attacker can trigger the conflict by issuing the two calls concurrently, causing the kernel to misapply the idr_replace function and treat a virtual memory object that is still in use as freeable or to install an invalid reference. The result is resource mismanagement that can lead to kernel instability or a denial of service. The underlying weakness is a concurrency control failure classified as CWE‑367.

Affected Systems

All Linux kernel releases that have not incorporated the commits remedial to the change_handle race condition are affected. No specific version range is supplied, so any kernel lacking the disclosed patches is vulnerable.

Risk and Exploitability

The CVSS score of 7.8 indicates high severity, while the EPSS score of < 1 % suggests a low likelihood of exploitation in the wild. The flaw is not listed in CISA’s KEV catalog and no public exploits are known. An attacker would need the ability to load a custom module or otherwise invoke privileged ioctl calls to trigger the race. Overall, the risk is moderate but timely remediation is recommended.

Generated by OpenCVE AI on June 28, 2026 at 14:24 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the fix for the change_handle race condition, or cherry‑pick the relevant upstream commits into the running kernel.
  • If immediate kernel update is not feasible, disable the gem_change_handle ioctl by applying a static patch or disabling the related DRM functionality in the kernel configuration.
  • Keep abreast of kernel release notes and security advisories for the DRM subsystem, and verify that the kernel in use contains the required commits.

Generated by OpenCVE AI on June 28, 2026 at 14:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 28 Jun 2026 08:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Fri, 26 Jun 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-367
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Important


Thu, 25 Jun 2026 09:15:00 +0000

Type Values Removed Values Added
Description 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.
Title drm/gem: Try to fix change_handle ioctl, attempt 4
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-07-15T00:44:51.168Z

Reserved: 2026-06-09T07:44:35.387Z

Link: CVE-2026-53145

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

Severity : Important

Publid Date: 2026-06-25T00:00:00Z

Links: CVE-2026-53145 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-28T14:30:07Z

Weaknesses
  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition