CVE-2026-64560 — Linux Kernel posix-cpu-timers 非 leader exec() 竞争 UAF

Reproducer / PoC（触发验证型）：Linux & Android (NDK) 本仓库仅用于在自有测试设备上验证补丁状态与研究学习，不包含任何提权/利用原语。

1. 漏洞概述

受影响版本

漏洞引入于 v5.7（2020-05），修复已 backport 到各 stable 分支：

Android 关联

Android GKI 内核基于 5.10 / 5.15 / 6.1 / 6.6 / 6.12 LTS，均在受影响范围内。由于主线修复提交发布于 2026-07-29，2026-08-01 及之前 SPL（安全补丁级别）的 Android 设备基本都未合入该修复。可在设备上用 adb shell cat /proc/version 与 getprop ro.build.version.security_patch 确认内核版本和 SPL。

2. 技术细节

2.1 背景：posix CPU timer 与 sighand

POSIX CPU 定时器（timer_create(CLOCK_PROCESS_CPUTIME_ID, ...) / timer_create(CLOCK_THREAD_CPUTIME_ID, ...)）在内核中由 kernel/time/posix-cpu-timers.c 管理。每个 k_itimer 通过 it.cpu.pid 记住目标任务；操作定时器时需要 lock_task_sighand(p, &flags) 拿到该 task 的 sighand->siglock 以保护 timerqueue。

2020 年的提交 55e8c8eb2c7b 把定时器里缓存的 task 指针换成了 pid 引用（为了修 2010 年 workaround e0a70217107e 引入的问题），每次操作前做 pid_task(pid, type) 查找。这个改动留下了本 CVE 的竞态窗口。

2.2 竞态场景（非 leader 线程 exec）

execve() 由非 leader 线程发起时，de_thread() → switch_leader() 会让 TGID 从旧 leader 转移到新 leader，旧 leader 走 release_task() → __exit_signal()，其中会把 old_leader->sighand = NULL 并 unhash_task(old_leader)。

与此同时，另一个 CPU 上执行的 sys_timer_delete() → posix_cpu_timer_del()：

 sys_timer_delete()                        exec()
   posix_cpu_timer_del()
   // 观察到旧 leader
   p = pid_task(pid, pid_type);            de_thread()
                                             switch_leader();
                                             release_task(old_leader)
                                               __exit_signal(old_leader)
                                                 sighand = lock(old_leader, sighand);
                                                 posix_cpu_timers*_exit();
   sighand = lock_task_sighand(p)            unhash_task(old_leader);
     sh = lock(p, sighand)                   old_leader->sighand = NULL;
                                               unlock(sighand);
     (p->sighand == NULL)
       unlock(sh)
       return NULL;

   // 直接返回，没有摘链！
   if (!sighand)
      return 0;
   free_posix_timer();   // ← k_itimer 被释放

posix_cpu_timer_del() 查到的 p 是旧 leader，此时 p->sighand == NULL，函数认为"任务正在退出，exit 路径会负责摘链"，于是什么都没做就返回成功。随后 free_posix_timer() 把 k_itimer 释放。

关键点：exec() 与 exit() 不同——exec() 时 TGID 不变，挂在进程级（p->signal->cpu_timers）的 armed 定时器会被继承、仍然入队。于是：

• run_posix_cpu_timers()（tick 中遍历 timerqueue）访问已释放对象的 timerqueue_node → UAF 读/写；
• 对其他定时器的 add/delete 操作同样会遍历到这棵含有悬空节点的 rbtree → UAF。

同类问题也存在于：

• posix_cpu_timer_set()：普通定时器只是暂时返回 -ESRCH；但内核内部的 do_cpu_nanosleep() 使用栈上分配的 k_itimer，是同样的 UAF。
• posix_cpu_timer_rearm()：静默 rearm 失败，定时器不再到期（功能性 bug）。

2.3 弱序架构上的次级问题

Frederic Weisbecker 指出：__exit_signal() 中 tsk->sighand = NULL 是普通存储，在 ARM64 等弱序架构上，posix_cpu_timer_del() 观察到 sighand == NULL 时并不保证能观察到 posix_cpu_timers*_exit() 之前的摘链写，导致 WARN_ON_ONCE(timer_queued(tmr)) 可能误报。

2.4 修复方案

1. __exit_signal() 中改为 smp_store_release(&tsk->sighand, NULL)；
2. lock_task_sighand() 的 !sighand 路径增加 smp_acquire__after_ctrl_dep()；
3. 新增 helper timer_lock_sighand()：查 task + 锁 sighand，若 sighand == NULL 不返回而是重试查找——exec 场景下会查到新 leader，exit 场景下查找失败才放弃；
4. 三个受影响函数（_del / _set / _rearm）统一改用该 helper。

完整 diff 见 patches/920f893f735e.patch。

3. PoC 说明（触发验证，非提权利用）

poc/ 下提供一个竞争触发器：两个线程分别高强度循环

• 线程 A（定时器线程）：反复 timer_create(CLOCK_PROCESS_CPUTIME_ID) → arm（很短的初始到期时间）→ 忙等触发 → timer_delete()；
• 线程 B（exec 线程）：反复 fork() → 子进程中创建非 leader 线程，由该线程调用 execve()（非 leader exec 是本漏洞的必要条件），父进程立即 waitpid() 回收。

当 timer_delete() 恰好与 de_thread()/__exit_signal() 竞争命中时，未打补丁的内核中已释放的 k_itimer 仍挂在 signal->cpu_timers 的 rbtree 上，之后 run_posix_cpu_timers() 或其他 timerqueue 操作将访问悬空节点。配合 KASAN 内核可稳定观测到 BUG: KASAN: use-after-free in run_posix_cpu_timers / timerqueue_del 等报告；无 KASAN 时通常表现为偶发内核警告或 panic。

性质说明：这是一枚纯 C 的 race 触发器，不包含 heap spray、对象占位、RIP 控制等任何利用原语。将其变成提权 exploit 需要额外的大量工作（堆风水、k_itimer 所在 slab cache 的占位对象、绕过 KASLR/CFI 等），且与具体内核构建强相关。本仓库刻意不包含这部分内容。

目录

├── README.md                ← 本文
├── patches/
│   └── 920f893f735e.patch   ← mainline 修复补丁全文
└── poc/
    ├── cve_2026_64560_poc.c ← 触发器源码（Linux/Android 通用）
    ├── Makefile             ← Linux / NDK 交叉编译
    └── Android.mk           ← NDK ndk-build（可选）

3.1 Linux x86_64 编译运行

cd poc
make                 # 生成 cve_2026_64560_poc
sudo ./cve_2026_64560_poc -d 60
# 观察 dmesg: sudo dmesg -wH | grep -iE 'kasan|use-after|BUG|WARNING'

3.2 Android（NDK 交叉编译，adb 推送）

cd poc
export ANDROID_NDK_HOME=/path/to/ndk
make android         # 生成 cve_2026_64560_poc_arm64（static, pie）

adb push cve_2026_64560_poc_arm64 /data/local/tmp/cvepoc
adb shell chmod 755 /data/local/tmp/cvepoc
adb shell /data/local/tmp/cvepoc -d 120

# 观察内核日志：
adb shell su 0 dmesg -w | grep -iE 'kasan|use-after|BUG|WARNING|timer'
# 无 root 时也可在触发崩溃后用 adb shell cat /sys/fs/pstore/console-ramoops* 查看

需要设备满足：

1. 内核版本在受影响区间（5.7 ~ 上表修复版本之前），SPL ≤ 2026-08-01 的设备基本都受影响；
2. 未打该补丁（打补丁后 PoC 只会空转退出）；
3. 想看到明确 KASAN 报告需要 KASAN 内核（自己编译的 GKI/boot.img 即可）；原厂内核触发成功时通常表现为 watchdog/panic 或无声损坏。

3.3 命中原理（为什么这样设计）

• CLOCK_PROCESS_CPUTIME_ID 定时器以 TGID 为目标 → 挂在 signal->cpu_timers，exec 后被继承 —— 这是 UAF 的前提（CLOCK_THREAD_CPUTIME_ID 不行）；
• 非 leader 线程 exec → switch_leader() 使 pid_task(TGID) 返回的旧 leader 随即 sighand = NULL —— 这是竞态的必要条件；
• 高频 timer_create/arm/delete + 高频 fork/exec 并行，最大化 posix_cpu_timer_del() 落在窗口内的概率；定时器到期处理（run_posix_cpu_timers）本身也会触碰悬节点，无需额外触发。

4. 自检：我的设备是否已修复？

# Android:
adb shell cat /proc/version            # 内核版本是否 >= 上表修复版本
adb shell getprop ro.build.version.security_patch   # SPL 是否 > 2026-08
# Linux:
uname -r
# 或直接检查源码是否包含 timer_lock_sighand:
grep -r timer_lock_sighand /usr/src/linux/kernel/time/posix-cpu-timers.c

跑 PoC 数分钟无任何 KASAN/panic 且内核 ≥ 修复版本，即视为已修复（PoC 本身也带 --check 模式做轻量冒烟验证）。

5. 参考链接

• CVE 记录：https://www.cve.org/CVERecord?id=CVE-2026-64560
• GitHub Advisory：https://github.com/advisories/GHSA-78ph-mc3q-52vv
• mainline 修复提交：https://github.com/torvalds/linux/commit/920f893f735e92ba3a1cd9256899a186b161928d
• 引入问题的提交 (v5.7)：https://github.com/torvalds/linux/commit/55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59
• 2010 年 workaround：https://github.com/torvalds/linux/commit/e0a70217107e
• SUSE 跟踪（含 Bugzilla 1273004/1273007）：https://www.suse.com/security/cve/CVE-2026-64560

免责声明 / Disclaimer

本仓库仅面向安全研究与防御验证。仅在您拥有或获得书面授权的设备上运行。PoC 会诱发内核不稳定甚至 panic，请勿在生产设备上运行。作者不对任何滥用造成的后果负责。