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グループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

このページでは、Linux/Android の POSIX CPU timers に存在する TOCTOU race によってタイマー状態が破損しカーネルがクラッシュする可能性、および特定の状況下では privilege escalation に繋がり得る点を解説します。

• 影響を受けるコンポーネント: kernel/time/posix-cpu-timers.c
• プリミティブ: expiry vs deletion race under task exit
• コンフィグ依存: CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n (IRQ-context expiry path)

簡潔な内部の要点（relevant for exploitation）

• 3 つの 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;
}

• Expiration は期限切れの timers を収集し、それらを firing とマークして queue から取り除きます。実際の配信は遅延されます:

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

2つの満了処理モード

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y: タイマー満了処理は対象の task 上の task_work 経由で遅延される
• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n: タイマー満了処理は IRQ コンテキストで直接処理される

IRQ-context パスでは、firing list は sighand の外で処理される

根本原因: タスク終了時の IRQ 時の期限切れと並行削除間の TOCTOU

前提条件

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK が無効（IRQ パスが使用される）
• 対象タスクは終了中だが完全には回収されていない
• 別スレッドが同じタイマーに対して posix_cpu_timer_del() を同時に呼ぶ

シーケンス

1. update_process_times() が、終了中のタスクに対して IRQ コンテキストで run_posix_cpu_timers() をトリガーする。
2. collect_timerqueue() は ctmr->firing = 1 を設定し、タイマーを一時的な firing リストに移動する。
3. handle_posix_cpu_timers() は unlock_task_sighand() により sighand を解放して、ロック外でタイマーを配信する。
4. unlock の直後に終了中のタスクが回収され得る；兄弟スレッドが posix_cpu_timer_del() を実行する。
5. この窓間において、posix_cpu_timer_del() は cpu_timer_task_rcu()/lock_task_sighand() を介して state を取得できず、結果として timer->it.cpu.firing を確認する通常の in-flight ガードをスキップする場合がある。削除は発火していないかのように進み、expiry が処理されている間に状態が破損してクラッシュや UB を引き起こす。

なぜ TASK_WORK モードは設計上安全か

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y の場合、expiry は task_work に延期される；exit_task_work は exit_notify より前に実行されるため、IRQ 時の回収との重なりは発生しない。
• それでもタスクが既に終了中であれば task_work_add() は失敗する；exit_state によるゲーティングにより両モードは一貫性を保つ。

修正（Android 共通カーネル）と理由

• 現在のタスクが終了中であれば早期リターンを追加し、すべての処理をゲートする：

// 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 を見逃して expiry processing と競合する可能性のあるウィンドウを排除します。

Impact

• 同時に expiry/削除 が発生する際に timer 構造体のカーネルメモリが破損すると、即時のクラッシュ（DoS）を引き起こす可能性があり、任意のカーネル状態を操作できるため privilege escalation に向けた強力な primitive になります。

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

• Ensure CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n and use a kernel without the exit_state gating fix.

Runtime strategy

• 終了しようとしているスレッドをターゲットにし、そこに CPU timer をアタッチします（per-thread or process-wide clock）:
• For per-thread: timer_create(CLOCK_THREAD_CPUTIME_ID, …)
• For process-wide: timer_create(CLOCK_PROCESS_CPUTIME_ID, …)
• ごく短い initial expiration と短い interval を設定して 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");
}

• 別のスレッドから、対象スレッドが終了する間に同じ timer を同時に削除する:

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

• レースを増幅する要因: 高いスケジューラの tick レート、CPU 負荷、スレッドの終了／再作成サイクルの繰り返し。クラッシュは通常、unlock_task_sighand() 直後のタスク検索／ロック失敗により posix_cpu_timer_del() が発火を見落とすときに発生する。

検出とハードニング

• 緩和策: exit_state ガードを適用する; 可能であれば CONFIG_POSIX_CPU_TIMERS_TASK_WORK を有効にすることを推奨。
• 可観測性: unlock_task_sighand()/posix_cpu_timer_del() 周辺に tracepoints/WARN_ONCE を追加する; it.cpu.firing==1 が cpu_timer_task_rcu()/lock_task_sighand() の失敗と同時に観測されたらアラートする; タスク終了時の timerqueue の不整合を監視する。

監査の注目箇所（レビュワー向け）

• 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

エクスプロイト調査向けメモ

• 公開された挙動は信頼できるカーネルクラッシュ原始（primitive）である; これを権限昇格に変えるには通常、本要約の範囲を超える追加の制御可能な重なり（オブジェクト寿命や write-what-where の影響など）が必要となる。PoC はシステムを不安定化する可能性があるため、エミュレータ/VM 上でのみ実行すること。

Chronomaly exploit strategy (priv-esc without fixed text offsets)

• Tested target & configs: x86_64 v5.10.157 under QEMU (4 cores, 3 GB RAM). Critical options: CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n, CONFIG_PREEMPT=y, CONFIG_SLAB_MERGE_DEFAULT=n, DEBUG_LIST=n, BUG_ON_DATA_CORRUPTION=n, LIST_HARDENED=n.
• Race steering with CPU timers: レースするスレッド（race_func()）が CPU を消費している間に CPU timers が発火し、free_func() はタイマーが発火したかを確認するために SIGUSR1 をポーリングする。CPU_USAGE_THRESHOLD を調整して信号が時々しか届かない状態（断続的に “Parent raced too late/too early” メッセージが出る）にする。毎回タイマーが発火するなら閾値を下げ、スレッド終了まで一度も発火しないなら閾値を上げる。
• Dual-process alignment into send_sigqueue(): 親子プロセスで send_sigqueue() 内の2度目のレースウィンドウを狙う。親はタイマーを設定する前に PARENT_SETTIME_DELAY_US マイクロ秒スリープする; 主に “Parent raced too late” が出る場合はこの値を下げ、主に “Parent raced too early” が出る場合は上げる。両方が出るならウィンドウを跨いでいることを示し、調整が整えば成功は概ね1分以内に期待できる。
• Cross-cache UAF replacement: エクスプロイトは struct sigqueue を free した後、アロケータの状態を調整する（sigqueue_crosscache_preallocs()）ことで、ダングリングの uaf_sigqueue と置換の realloc_sigqueue の両方が pipe buffer のデータページ上に配置される（cross-cache reallocation）。信頼性は事前の sigqueue 割り当てが少ない静かなカーネルを想定している; per-CPU/per-node の部分的な slab ページが既に存在する（負荷の高いシステム）と置換が失敗してチェーンが崩れる。作者はノイズの多いカーネル向けに最適化を意図的に行っていない。

関連

Ksmbd Streams Xattr Oob Write Cve 2025 37947

参考資料

• Race Against Time in the Kernel’s Clockwork (StreyPaws)
• Android security bulletin – September 2025
• Android common kernel patch commit 157f357d50b5…
• Chronomaly exploit PoC (CVE-2025-38352)
• CVE-2025-38352 analysis – Part 1
• CVE-2025-38352 analysis – Part 2
• CVE-2025-38352 analysis – Part 3

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グループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。