Linux · Kernel · Linux Kernel Time-of-Check Time-of-Use (TOCTOU) Race Condition Vulnerability
Verdict
Patch on your normal cycle · actively exploited, not reachable unauthenticated from the internet, and in the top half of CVEs by near-term exploitation probability
Added to CISA KEV 2025-09-04 · exploited in the wild for 388 days
CVSS 7.8 HIGH. The score is a summary; these three components are the part that decides whether something scanning the internet can use it.
| Attack vector | localrequires local access to the machine |
|---|---|
| Privileges required | lowneeds some credentials, so a fully anonymous attacker cannot reach it directly |
| User interaction | nonecan be triggered with nobody interacting with the page or request |
| Base vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| Weakness | CWE-367 |
This describes the vulnerability. It says nothing about whether your systems run it.
EPSS puts the probability of exploitation in the next 30 days at 0.0130, which places it in the top half of all tracked CVEs. The percentile is the more useful half: 0.18 in absolute terms sounds low until you know most of the internet-facing software in the world scores under that.
| EPSS probability | 0.0130 |
|---|---|
| Percentile | 0.692 — top half |
| Added to KEV | 2025-09-04 |
|---|---|
| Days exploited | 388 |
| Federal remediation due | not set |
| Ransomware use | no known ransomware campaign use |
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
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.