Cyber Resilience

CVE-2026-53145

Race Condition in Linux Kernel 6.18.32 – 6.18.36

Published
25 June 2026
Modified
15 July 2026
Patch / advisory
CVSS Score v3.1 7.8
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score 0.00099 0.9th percentile
Risk Priority 55 floored blend · peak EPSS

Summary

CVE-2026-53145 is a high-severity Time-of-check Time-of-use (TOCTOU) Race Condition (CWE-367) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Path Interception (T1034); ranked at the 0.9th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to AC-25 (Reference Monitor) and AC-3 (Access Enforcement) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

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…

more

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.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1034 Path Interception Persistence
**This technique has been deprecated.
T1548 Abuse Elevation Control Mechanism Privilege Escalation
Adversaries may circumvent mechanisms designed to control privilege elevation to gain higher-level permissions.
T1574 Hijack Execution Flow Stealth
Adversaries may execute their own malicious payloads by hijacking the way operating systems run programs.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2023-4155Same product: Linux Linux Kernel
CVE-2025-38217Same product: Linux Linux Kernel
CVE-2025-22060Same product: Linux Linux Kernel
CVE-2026-64091Same product: Linux Linux Kernel
CVE-2025-21958Same product: Linux Linux Kernel
CVE-2026-53250Same product: Linux Linux Kernel
CVE-2024-43882Same product: Linux Linux Kernel
CVE-2024-50234Same product: Linux Linux Kernel
CVE-2025-21746Same product: Linux Linux Kernel
CVE-2026-31678Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
7.1 · 6.18.32 — 6.18.36 · 7.0.9 — 7.0.13
redhat
enterprise linux
10.0, 7.0, 8.0, 9.0

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V15.4.2
  • V17.2.6

Mitigating Controls (NIST 800-53 r5) AI

A reference monitor that is always invoked and analyzable structurally eliminates the non-atomic check-then-use pattern underlying TOCTOU.

Access enforcement that performs an atomic check-and-use decision directly stops the window in which a TOCTOU race can be exploited.

Process isolation limits the blast radius of a successful TOCTOU exploitation but does not remove the race itself.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly include coding standards and reviews that prevent TOCTOU race conditions.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

none

Reliable, synchronized time across systems narrows the exploitable window in which a resource state can change between a security check and its use.

References