from disclosure to weapon152 days
What the vendors declare (VEX)
Official vendor statements in CSAF/VEX format: whether their product is affected, already fixed, or ruled out — and why. These are the vendor's assertions, not Vexday's judgment.
Fixed37 products (1,985 components)
Red Hat Enterprise Linux BaseOS EUS (v.9.4) · Red Hat Enterprise Linux BaseOS E4S (v.9.2) · Red Hat Enterprise Linux BaseOS (v. 8) · Red Hat Enterprise Linux BaseOS E4S (v.8.6) · Red Hat Enterprise Linux BaseOS (v. 9) · and others 32
Not affected19 products (32 components) — because the vulnerable code is not present in the product
Red Hat Enterprise Linux 6 · Red Hat Enterprise Linux AppStream (v. 10) · Red Hat Enterprise Linux AppStream (v. 9) · Red Hat Enterprise Linux AppStream E4S (v.9.0) · Red Hat Enterprise Linux AppStream E4S (v.9.2) · and others 14
Action required by CISAfederal deadline: 2025-09-25
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 short
A race condition in Linux kernel POSIX CPU timers can cause a crash or unpredictable behavior when a task exits while its timer is being deleted concurrently. The kernel fails to properly synchronize access to timer data during the exit process.
Technical detail
CWE-367 (Time-of-check Time-of-use race condition) in posix-cpu-timers: handle_posix_cpu_timers() executing from IRQ on an exiting non-autoreaping task can race with concurrent posix_cpu_timer_del(), allowing the latter to proceed without detecting firing timers when lock_task_sighand() or cpu_timer_task_rcu() fail post-reaping. Fix adds exit_state validation in run_posix_cpu_timers() to prevent timer operations on exiting tasks.
Summary generated and translated by AI from the official description.
The full analysis of this CVE is available in Portuguese →
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.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
⚠ Public resources, to assess the exposure of systems you control or are authorized to test. Test only with authorization.
Related CVEs — Linux
In the same product, most dangerous first.