CVE-2014-3153

Falha no subsistema futex do kernel Linux que permite a um usuário local sem privilégios escalar para execução de código em ring 0, geralmente terminando em root. Ficou famosa como base do Towelroot, ferramenta de root para dispositivos Android, e é citada por pesquisadores da época como uma das falhas de kernel Linux mais graves da década por funcionar mesmo dentro de sandboxes restritos, já que futex é primitiva usada pelo pthread da glibc e costuma estar acessível.

O bug está em kernel/futex.c, na função futex_requeue, usada pela operação FUTEX_REQUEUE_PI. A chamada recebe dois endereços de futex (uaddr1 e uaddr2) e deveria garantir que são distintos antes de mover ('requeue') um waiter da fila do primeiro para a fila do segundo com semântica PI (priority inheritance). O código não validava essa condição: um processo podia invocar FUTEX_REQUEUE_PI passando o mesmo endereço para uaddr1 e uaddr2 (ou endereços que mapeiam para a mesma chave interna, no caso de futexes compartilhados/shared).

O vetor é 100% local: o atacante precisa apenas de capacidade de executar syscalls arbitrárias como usuário sem privilégios — não requer configuração especial, serviço de rede exposto ou CVE encadeada de acesso inicial. Isso inclui contextos de sandbox restritos (containers, sandboxes de browser/app), porque futex é usado internamente pela implementação de mutex da glibc e normalmente não é bloqueado por seccomp em configurações comuns da época.

A exploração pública demonstrada consiste em usar FUTEX_REQUEUE_PI com uaddr1 igual a uaddr2 (ou chaves colidentes) para deixar uma estrutura de waiter em estado inconsistente na pilha do kernel; syscalls subsequentes manipulam essa estrutura antes que ela seja processada na função de wake-up, corrompendo estado interno do kernel. Dependendo da técnica, o resultado varia de kernel panic (DoS) a corrupção controlada que leva à execução de código em modo kernel — é essa segunda via que foi usada no Towelroot e em PoCs públicas, incluindo módulo Metasploit.

Há exploração ativa confirmada (a falha está no catálogo KEV da CISA), e existe PoC pública amplamente disponível, o que torna a barreira de exploração baixa para quem tem acesso a shell não privilegiado em kernel vulnerável.

A correção oficial (commit e9c243a5a6de0be8e584c604d353412584b592f8, upstream) adiciona a checagem que faltava: recusa (retorna -EINVAL) quando uaddr1 == uaddr2, e complementa com uma segunda verificação baseada nas chaves internas do futex (match_futex) para cobrir o caso de futexes compartilhados onde endereços diferentes podem mapear para a mesma chave. O patch cobre tanto futex_requeue quanto futex_wait_requeue_pi.

A correção definitiva é atualizar o kernel para uma versão que inclua esse commit — distribuições enterprise (Oracle Linux, openSUSE, entre outras, conforme os errata ELSA-2014-0771/3037/3038/3039 e os anúncios de segurança do openSUSE) fizeram backport para seus kernels suportados na época; a versão exata de correção depende do branch/distro e deve ser conferida no advisory correspondente, já que não há aqui uma tabela consolidada de números de versão por distribuição.

Como paliativo quando atualização imediata não é viável: restringir acesso à syscall futex via seccomp-bpf (bloqueando ou filtrando FUTEX_REQUEUE_PI) reduz a superfície, mas quebra funcionalidade de qualquer processo que dependa de mutexes PI da glibc — custo alto e não é solução recomendada como substituto do patch. Não existe mitigação de configuração 'leve' (sysctl, montagem, etc.) documentada nas fontes consultadas; o requeue via futex é um mecanismo interno de sincronização, não algo desabilitável de forma granular sem tocar em seccomp.

Não há assinatura de rede, já que o vetor é inteiramente local via syscalls (futex com FUTEX_REQUEUE_PI). Em ambientes com auditoria de syscalls (auditd/eBPF), monitorar chamadas futex com a flag FUTEX_REQUEUE_PI onde uaddr1 e uaddr2 coincidem ou apontam para a mesma página pode indicar tentativa de exploração, mas isso exige instrumentação prévia — não é algo visível em logs padrão do sistema. Kernel panics inexplicados em hosts multiusuário ou em sandboxes que executam código não confiável são um sinal indireto a investigar retroativamente.