CVE-2026-64560 — Linux Kernel posix-cpu-timers corrida UAF em exec() de thread não-líder

Reproducer / PoC (validação de gatilho) : Linux e Android (NDK) Este repositório destina-se apenas a verificar o estado do patch e estudo/pesquisa nos seus próprios dispositivos de teste, não contém nenhuma primitiva de escalonamento/exploração.

1. Resumo da vulnerabilidade

Versões afetadas

A vulnerabilidade foi introduzida na v5.7 (2020-05); a correção foi aplicada também (backport) em vários ramos estáveis:

Relação com Android

Os kernels GKI do Android são baseados nos LTS 5.10 / 5.15 / 6.1 / 6.6 / 6.12, todos dentro do escopo afetado. Como o commit de correção na mainline foi publicado em 2026-07-29, os dispositivos Android com SPL (Security Patch Level) de 2026-08-01 ou anterior praticamente não incluem essa correção. No dispositivo, use adb shell cat /proc/version e getprop ro.build.version.security_patch para confirmar a versão do kernel e o SPL.

2. Detalhes técnicos

2.1 Contexto: timers de CPU POSIX e sighand

Os timers de CPU POSIX (timer_create(CLOCK_PROCESS_CPUTIME_ID, ...) / timer_create(CLOCK_THREAD_CPUTIME_ID, ...)) são gerenciados no kernel por kernel/time/posix-cpu-timers.c. Cada k_itimer lembra a tarefa alvo através de it.cpu.pid; ao operar no timer é necessário obter o sighand->siglock da tarefa via lock_task_sighand(p, &flags) para proteger a timerqueue.

O commit de 2020, 55e8c8eb2c7b, trocou o ponteiro de task armazenado em cache no timer por uma referência a pid (para corrigir o problema introduzido pelo workaround de 2010 e0a70217107e), fazendo uma busca pid_task(pid, type) antes de cada operação. Essa mudança deixou a janela de corrida deste CVE.

2.2 Cenário da corrida (exec de thread não-líder)

Quando execve() é iniciado por uma thread não-líder, de_thread() → switch_leader() transfere o TGID do líder antigo para o novo líder; o líder antigo passa por release_task() → __exit_signal(), que define old_leader->sighand = NULL e executa unhash_task(old_leader).

Enquanto isso, sys_timer_delete() → posix_cpu_timer_del() executando em outra CPU:

 sys_timer_delete()                        exec()
   posix_cpu_timer_del()
   // observa o líder antigo
   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;

   // retorna direto, sem remover da fila!
   if (!sighand)
      return 0;
   free_posix_timer();   // ← k_itimer é liberado

O p encontrado por posix_cpu_timer_del() é o líder antigo; nesse momento, p->sighand == NULL, e a função considera que "a tarefa está saindo, o caminho de exit cuidará da remoção da fila", portanto não faz nada e retorna sucesso. Em seguida, free_posix_timer() libera o k_itimer.

Ponto-chave: exec() é diferente de exit() — em exec(), o TGID não muda; os timers armados (armed) no nível do processo (p->signal->cpu_timers) são herdados e permanecem enfileirados. Assim:

• run_posix_cpu_timers() (que percorre a timerqueue no tick) acessa o timerqueue_node de um objeto já liberado → UAF de leitura/escrita;
• operações de add/delete em outros timers também percorrem essa rbtree contendo um nó pendurado (dangling) → UAF.

Problemas semelhantes também existem em:

• posix_cpu_timer_set(): um timer comum apenas retorna -ESRCH temporariamente; mas o do_cpu_nanosleep() interno do kernel usa um k_itimer alocado na pilha, sofrendo o mesmo UAF.
• posix_cpu_timer_rearm(): o rearm falha silenciosamente e o timer nunca mais expira (bug funcional).

2.3 Problema secundário em arquiteturas com ordenação fraca

Frederic Weisbecker apontou: em __exit_signal(), tsk->sighand = NULL é um armazenamento comum; em arquiteturas de ordenação fraca, como ARM64, quando posix_cpu_timer_del() observa sighand == NULL, não é garantido que observe as escritas de remoção da fila anteriores a posix_cpu_timers*_exit(), podendo causar falsos positivos de WARN_ON_ONCE(timer_queued(tmr)).

2.4 Correção aplicada

1. Em __exit_signal(), alterado para smp_store_release(&tsk->sighand, NULL);
2. No caminho !sighand de lock_task_sighand(), adicionado smp_acquire__after_ctrl_dep();
3. Novo helper timer_lock_sighand(): localiza a task + obtém o lock do sighand; se sighand == NULL, não retorna, mas tenta a busca novamente — no cenário de exec encontrará o novo líder; no cenário de exit, a busca falha e só então desiste;
4. As três funções afetadas (_del / _set / _rearm) passam a usar esse helper.

O diff completo está em patches/920f893f735e.patch.

3. Explicação do PoC (gatilho de validação, não exploit de escalonamento)

Em poc/ há um gatilho de corrida: duas threads executam loops intensos:

• Thread A (thread do timer): repetidamente timer_create(CLOCK_PROCESS_CPUTIME_ID) → arm (com tempo inicial de expiração muito curto) → busy-wait até disparar → timer_delete();
• Thread B (thread de exec): repetidamente fork() → no processo filho, cria uma thread não-líder que chama execve() (exec de thread não-líder é condição necessária desta vulnerabilidade); o processo pai imediatamente faz waitpid() para reclamar.

Quando timer_delete() coincide com de_thread()/__exit_signal() na corrida, em um kernel sem o patch o k_itimer já liberado ainda está pendurado na rbtree de signal->cpu_timers; depois, run_posix_cpu_timers() ou outras operações de timerqueue acessarão o nó pendurado. Com um kernel KASAN, é possível observar de forma estável relatos como BUG: KASAN: use-after-free in run_posix_cpu_timers / timerqueue_del; sem KASAN, normalmente aparecem avisos esporádicos do kernel ou panic.

Natureza: este é um gatilho de corrida puramente em C, sem heap spray, ocupação de objeto, controle de RIP ou qualquer primitiva de exploração. Transformá-lo em um exploit de escalonamento exigiria muito trabalho adicional (heap feng shui, objetos de ocupação no slab cache do k_itimer, contornar KASLR/CFI etc.) e é fortemente dependente da construção específica do kernel. Este repositório deliberadamente não inclui essa parte.

Estrutura de diretórios

├── README.md                ← este documento
├── patches/
│   └── 920f893f735e.patch   ← patch completo da correção na mainline
└── poc/
    ├── cve_2026_64560_poc.c ← código-fonte do gatilho (comum a Linux/Android)
    ├── Makefile             ← compilação cruzada Linux / NDK
    └── Android.mk           ← NDK ndk-build (opcional)

3.1 Compilação e execução no Linux x86_64

cd poc
make                 # gera cve_2026_64560_poc
sudo ./cve_2026_64560_poc -d 60
# observe o dmesg: sudo dmesg -wH | grep -iE 'kasan|use-after|BUG|WARNING'

3.2 Android (compilação cruzada com NDK, push via adb)

cd poc
export ANDROID_NDK_HOME=/path/to/ndk
make android         # gera 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

# Observe o log do kernel:
adb shell su 0 dmesg -w | grep -iE 'kasan|use-after|BUG|WARNING|timer'
# Sem root, também é possível ver após o crash com: adb shell cat /sys/fs/pstore/console-ramoops*

O dispositivo precisa atender a:

1. Versão do kernel dentro da faixa afetada (5.7 ~ versões anteriores à correção na tabela acima); dispositivos com SPL ≤ 2026-08-01 são, em geral, afetados;
2. Não ter esse patch aplicado (com o patch, o PoC apenas roda e sai sem efeito);
3. Para ver relatórios KASAN claros, é necessário um kernel KASAN (pode ser um GKI/boot.img compilado por você); em kernels de fábrica, um gatilho bem-sucedido normalmente se manifesta como watchdog/panic ou corrupção silenciosa.

3.3 Princípio de acerto (por que foi projetado assim)

• Um timer CLOCK_PROCESS_CPUTIME_ID tem como alvo o TGID → fica em signal->cpu_timers e é herdado após exec — esse é o pré-requisito do UAF (CLOCK_THREAD_CPUTIME_ID não funciona);
• exec por thread não-líder → switch_leader() faz com que o líder antigo retornado por pid_task(TGID) fique imediatamente com sighand = NULL — essa é a condição necessária para a corrida;
• timer_create/arm/delete em alta frequência + fork/exec em alta frequência em paralelo maximizam a probabilidade de posix_cpu_timer_del() cair dentro da janela; o próprio tratamento de expiração do timer (run_posix_cpu_timers) também toca o nó pendurado, sem necessidade de gatilho adicional.

4. Autoverificação: meu dispositivo já está corrigido?

# Android:
adb shell cat /proc/version            # a versão do kernel é >= à versão corrigida na tabela acima?
adb shell getprop ro.build.version.security_patch   # o SPL é > 2026-08?
# Linux:
uname -r
# ou verifique diretamente se o código-fonte contém timer_lock_sighand:
grep -r timer_lock_sighand /usr/src/linux/kernel/time/posix-cpu-timers.c

Se o PoC rodar por alguns minutos sem nenhum KASAN/panic e o kernel for ≥ à versão corrigida, considere corrigido (o PoC também possui um modo --check para uma validação leve de fumaça).

5. Links de referência

• Registro CVE: https://www.cve.org/CVERecord?id=CVE-2026-64560
• GitHub Advisory: https://github.com/advisories/GHSA-78ph-mc3q-52vv
• Commit de correção na mainline: https://github.com/torvalds/linux/commit/920f893f735e92ba3a1cd9256899a186b161928d
• Commit que introduziu o problema (v5.7): https://github.com/torvalds/linux/commit/55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59
• Workaround de 2010: https://github.com/torvalds/linux/commit/e0a70217107e
• Rastreamento da SUSE (inclui Bugzilla 1273004/1273007): https://www.suse.com/security/cve/CVE-2026-64560

Aviso de isenção / Disclaimer

Este repositório destina-se exclusivamente a pesquisa de segurança e validação defensiva. Execute apenas em dispositivos que você possua ou para os quais tenha autorização por escrito. O PoC pode induzir instabilidade no kernel e até panic; não execute em dispositivos de produção. Os autores não se responsabilizam por consequências de qualquer uso indevido.