CVE-2026-53145
published 2026-06-25CVE-2026-53145: 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…
PriorityP337high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.11%
1.3th percentile
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 corre
Affected
20 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 5e28b7b94408897e41c63477aabc9e1db439bc8c < 1a4f03d22fb655e5f192244fb2c87d8066fcfca2 | 1a4f03d22fb655e5f192244fb2c87d8066fcfca2 |
| linux | linux | >= 6.18.32 < 6.18.36 | 6.18.36 |
| linux | linux | >= 61bd96d3e5472c253f9c1ab77608f0c8aaa9d025 < 1d9b93df7fc768228906e24220591ec1cddad391 | 1d9b93df7fc768228906e24220591ec1cddad391 |
| linux | linux | >= 672464dd53231509c9c771110798c56d4660e19e < c0639ede2f24ac224b2079cd35ecd5fd8ad4e3cd | c0639ede2f24ac224b2079cd35ecd5fd8ad4e3cd |
| linux | linux | >= 7.0.9 < 7.0.13 | 7.0.13 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 6.18.32 < 6.18.36 | 6.18.36 |
| linux | linux_kernel | >= 7.0.9 < 7.0.13 | 7.0.13 |
| redhat | enterprise_linux | — | — |
| redhat | enterprise_linux | — | — |
| redhat | enterprise_linux | — | — |
| redhat | enterprise_linux | — | — |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vendor_redhat7.0HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 6.18.35/7.0.12 anymore race condition (WID-SEC-2026-2077)
vuldb·2026-06-28·CVSS 7.8
CVE-2026-53145 [HIGH] Linux Kernel up to 6.18.35/7.0.12 anymore race condition (WID-SEC-2026-2077)
A vulnerability was found in Linux Kernel up to 6.18.35/7.0.12 and classified as critical. This affects an unknown part of the component anymore. Executing a manipulation can lead to race condition.
The identification of this vulnerability is CVE-2026-53145. The attack needs to be done within the local network. There is no exploit available.
It is suggested to upgrade the affected component.
GHSA
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
ghsa_unreviewed·2026-06-25
CVE-2026-53145 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
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 t
Red Hat
kernel: drm/gem: Try to fix change_handle ioctl, attempt 4
vendor_redhat·2026-06-25·CVSS 7.0
CVE-2026-53145 [HIGH] CWE-367 kernel: drm/gem: Try to fix change_handle ioctl, attempt 4
kernel: drm/gem: Try to fix change_handle ioctl, attempt 4
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 th
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/1a4f03d22fb655e5f192244fb2c87d8066fcfca2https://git.kernel.org/stable/c/1d9b93df7fc768228906e24220591ec1cddad391https://git.kernel.org/stable/c/c0639ede2f24ac224b2079cd35ecd5fd8ad4e3cdhttps://access.redhat.com/security/cve/CVE-2026-53145https://bugzilla.redhat.com/show_bug.cgi?id=2492773https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53145.json
2026-06-25
Published