CVE Alert: CVE-2025-38352 – Linux – Linux
CVE-2025-38352
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.
AI Summary Analysis
Risk verdict
High risk to systems running affected Linux kernels; no confirmed exploitation yet, but the local TOCTOU race warrants prompt patching when feasible.
Why this matters
The race between timer handling and timer deletion can enable a local attacker to corrupt timer state, potentially leading to privilege escalation or kernel instability. With a high impact on confidentiality, integrity and availability and no user interaction required, compromised hosts or multi-tenant environments are at elevated risk once local access is gained.
Most likely attack path
An attacker already on the host with local access could attempt a timing-based race against POSIX CPU timer code, triggering inconsistent states or failures in task sighandling. Exploitation is technically complex (high attack complexity) and requires aligning handle_posix_cpu_timers with concurrent timer deletion, but it does not require user interaction. Lateral movement is limited by the local-attack vector, but compromised hosts could be pivot points in larger environments.
Who is most exposed
Servers, cloud/hypervisor hosts and containerised workloads running affected kernel versions are most exposed; embedded or desktop deployments using older or unpatched kernels in the affected range are also at risk.
Detection ideas
- Kernel oops/panics or warning messages in dmesg related to posix_cpu_timers or lock_task_sighand.
- Unusual task termination or reaping patterns around exiting threads.
- Anomalies in timer-related syscalls or heavy timer churn under load.
- Post-mortem crash dumps referencing timer_del or sighand paths.
- Audit logs showing mismatches in timer state transitions.
Mitigation and prioritisation
- Apply the patched kernel version from your distribution and verify the fix is present.
- If rebuilding is required, enable relevant config (where feasible) such as TASK_WORK variants that mitigate this race.
- Enforce strict local access controls; apply least-privilege policies to services/processes that can interact with timer APIs.
- Implement compensating controls: endpoint hardening, container isolation, and monitoring for abnormal timer activity.
- Plan a staged patch deployment with validation in a test environment; communicate downtime and rollback procedures.
A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.
If you like the site, please support us on “Patreon” or “Buy Me A Coffee” using the buttons below
To keep up to date follow us on the below channels.
