CVE-2025-38352: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()
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.
Security readout for executives and security teams
Plain-English summary
A race condition in Linux CPU-timer handling can occur while a process is exiting and being reaped. A local, low-privileged attacker may exploit it with potentially serious confidentiality, integrity, and availability consequences. Internet exposure alone is insufficient; the attacker must already be able to execute code locally.
Executive priority
Treat remediation as urgent because CISA identifies the vulnerability as known exploited and potential impact spans confidentiality, integrity, and availability. Accelerate kernel maintenance on multi-user and untrusted-workload systems, while validating exposure through distribution-specific guidance rather than assuming all Linux installations are equally affected.
Technical view
CVE-2025-38352 is a CWE-367 race between handle_posix_cpu_timers() and posix_cpu_timer_del() after exit_notify(). Reaping can make task lookup or locking fail, preventing detection of a firing timer. The stable fix makes run_posix_cpu_timers() check the task's exit state. CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y avoids the vulnerable ordering.
Likely exposure
Exposure includes systems running the listed affected Linux versions, particularly shared hosts or systems executing untrusted local workloads. The source says the fix is unnecessary when CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y. Exact distribution-package exposure requires vendor verification because the supplied version and commit data do not provide a complete package matrix.
Exploitation context
CISA KEV inclusion supports active exploitation. The bundle also references a public exploit repository, increasing practical concern, but it does not establish the exploit's reliability, affected campaigns, victims, or scale. The supplied CVSS vector indicates exploitation requires local access and low privileges, without user interaction.
Researcher notes
The supplied affected-version data is difficult to interpret: a commit hash repeats, and several versions may represent branch boundaries. Validate applicability against the stable commits and distribution advisories. The bundle provides no crash signature, forensic indicators, exploitation telemetry, or reliability assessment. Avoid inferring remote exploitability; the CVSS vector specifies local access.
Mitigation direction
Install a supported vendor kernel containing the applicable stable fix, then reboot into the updated kernel.
Prioritize shared systems, developer platforms, and hosts where untrusted users or workloads can execute code.
Confirm whether CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y applies before relying on the documented configuration exception.
Reduce untrusted local code access on exposed hosts until kernel remediation is completed.
Validation and detection
Inventory running kernel releases and vendor package versions across Linux systems.
Verify the running kernel contains the applicable fix or vendor backport, not merely an installed update.
Check each kernel build's CONFIG_POSIX_CPU_TIMERS_TASK_WORK setting where the documented exception may apply.
After rebooting, confirm systems are running the remediated kernel.
Do not treat absent alerts as proof of safety; the sources provide no detection indicators.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-367: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
Exploitation: activeAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-367 · source CWE mapping
Time-of-check Time-of-use (TOCTOU) Race Condition
Time-of-check Time-of-use (TOCTOU) Race Condition represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.