IRONSMITHINTEL
HIGHCVSS7.4
|
Actively Exploited
|CISA KEV|CVE-2025-38352|Auth: none — unauthenticated|Reboot: required|Manual only

Linux Kernel Time-of-Check Time-of-Use (TOCTOU) Race Condition Vulnerability (CVE-2025-38352)

Linux kernel contains a time-of-check time-of-use (TOCTOU) race condition vulnerability that has a high impact on confidentiality, integrity, and availability.

Published Jul 22, 2025 · Updated May 17, 2026
Why patchRisk explained in plain English
Worst-case scenarioIf unpatched

A local attacker, without authentication, can achieve full data confidentiality loss, arbitrary modification of data, complete denial of service or system unavailability. Federal agencies are required to remediate by 2025-09-25 under CISA BOD 22-01.

How the attack worksNo clicks needed

This is a Software Vulnerability (CWE-367) (CWE-367) vulnerability in Linux Kernel. In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case. Exploitation requires local access, higher attack complexity, no authentication required, and no user interaction required.

Am I affected?Quick check

Probably yes if any of these apply:

IT Security
Running linux kernel: 2.6.36 ≤ v < 5.4.295, 5.5 ≤ v < 5.10.239, 5.11 ≤ v < 5.15.186, 5.16 ≤ v < 6.1.142, 6.2 ≤ v < 6.6.94, 6.7 ≤ v < 6.12.34, 6.13 ≤ v < 6.15.3, 6.16; debian linux: 11.0
Real-world incidentsWhat we've seen

Active exploitation documented in the wild. Threat-research write-up: https://github.com/farazsth98/chronomaly

How to patch

Manual remediation steps

1
Identify affected hosts: query inventory for general installs in scope.
2
Apply the vendor security update referenced in CVE-2025-38352's advisory. No specific KB/version is encoded yet — consult the linked MSRC/vendor URL.
3
Verify the fix per the vendor's published verification steps.
4
Document the remediation in your change ticket and re-scan with your vulnerability scanner to confirm closure.
PowerShell automationComing soon

No tested PowerShell script for this entry yet. We’re prioritising automation based on user demand.