CVE-2022-38181

Use-after-free (CWE-416) no driver de kernel da GPU Arm Mali, nas famílias Bifrost, Valhall e Midgard, no subsistema de gerenciamento de memória JIT (just-in-time memory, usada como cache de páginas GPU, não relacionada a compilação JIT). Permite que um app sem privilégios no Android obtenha execução de código no kernel e root. Está no catálogo KEV da CISA com exploração confirmada e PoC pública, mas a exploração exige acesso local ao dispositivo (app instalado), não é uma falha remota apesar do vetor CVSS AV:N.

A falha está na gestão de regiões de memória JIT (kbase_va_region) do driver kbase. Quando um app aloca memória JIT via job soft BASE_JD_REQ_SOFT_JIT_ALLOC (submetido por KBASE_IOCTL_JOB_SUBMIT), a função kbase_jit_allocate_process guarda um ponteiro para a região recém-criada no array kctx->jit_alloc[info->id]. Essa referência não é limpa em nenhum outro ponto do ciclo de vida da região.

Se o atacante, via ioctl KBASE_IOCTL_MEM_FLAGS_CHANGE, marcar a mesma região com a flag KBASE_REG_DONT_NEED, ela é movida para a lista evict_list do kbase_context. Sob pressão de memória — por exemplo forçando o kernel a acionar o shrinker registrado (kctx->reclaim) via reclaim direto, o que pode ser induzido mapeando grandes quantidades de memória — kbase_mem_evictable_reclaim_scan_objects percorre evict_list e chama kbase_jit_backing_lost, que move a região para jit_destroy_head e agenda sua liberação via schedule_work. A memória é efetivamente liberada, mas o ponteiro em kctx->jit_alloc continua válido (dangling).

Um uso subsequente de kbase_jit_free sobre esse ID reaproveita o ponteiro já liberado, gerando use-after-free clássico: o atacante controla o timing (quando dispara a pressão de memória) e o conteúdo realocado na região liberada, o que viabiliza corrupção de estruturas do kernel e, no PoC divulgado, execução arbitrária de código no kernel com escalada a root.

A vulnerabilidade foi encontrada e documentada por Man Yue Mo (GitHub Security Lab / GHSL-2022-054), testada especificamente no driver do Pixel 6 (kernel android-gs-raviole-5.10), mas o defeito está no código genérico do driver Mali, afetando qualquer dispositivo que use as versões listadas — não é um problema exclusivo do Pixel, apesar da avaliação inicial do time de segurança do Android como 'device-specific'.

O vetor é estritamente local: exige que o atacante execute código (um app) no dispositivo Android (ou outro sistema com GPU Mali) com acesso ao nó do driver Mali, algo disponível para qualquer app sem privilégios especiais, já que drivers de GPU são acessíveis diretamente do domínio untrusted_app no Android. Não há componente de rede nem exige interação do usuário.

A cadeia de exploração documentada publicamente (GHSL-2022-054 / PoC do pesquisador) envolve: (1) alocar uma região JIT via job soft de alocação; (2) marcá-la como 'não necessária' via KBASE_IOCTL_MEM_FLAGS_CHANGE, movendo-a para evict_list; (3) forçar reclaim de memória do kernel (ex.: pressão via mmap de grandes blocos) para que o shrinker libere a região enquanto o ponteiro em jit_alloc permanece; (4) usar esse ponteiro obsoleto via kbase_jit_free para acionar o UAF e, a partir daí, manipular estruturas do kernel para obter execução de código arbitrário e escalada de privilégio a root.

O próprio pesquisador demonstrou o exploit completo — allocação e rooting de um Pixel 6 a partir de um app não confiável — e o compartilhou com o time de segurança do Android em julho de 2022. A CISA lista a CVE no catálogo KEV com exploração confirmada in-the-wild, embora sem atribuição a campanha de ransomware conhecida.

A correção oficial da Arm está na versão r40p0 do driver Mali, lançada em 07/10/2022, que corrige o vazamento de referência ao ponteiro liberado. Não há flag de configuração, mitigação de runtime ou desativação de recurso documentada pelas fontes consultadas — a correção é código no driver, portanto depende do fabricante do SoC/dispositivo incluir r40p0 (ou versão posterior corrigida) no kernel/firmware entregue ao usuário final.

Em dispositivos Android, isso significa aguardar o patch de segurança do fabricante que incorpore o driver corrigido; no caso dos Pixel, a correção só chegou na atualização de janeiro de 2023 (referenciada internamente como bug 259695958), sem menção ao CVE ou ao bug original no boletim de segurança — um sinal de que rastrear a correção apenas pelo changelog público pode não ser suficiente; convém confirmar a versão real do driver Mali instalada.

Não há mitigação eficaz que não seja atualizar o driver: como o vetor exige apenas execução local de código sem privilégio elevado, restringir instalação de apps de fontes não confiáveis reduz a superfície mas não elimina o risco em dispositivos com apps maliciosos já instalados ou com outra falha de execução de código anterior na cadeia.

Não há assinatura de rede ou log de aplicação confiável, pois a exploração é inteiramente local, via chamadas ioctl ao nó de dispositivo do driver Mali (ex.: /dev/mali0) e jobs submetidos por KBASE_IOCTL_JOB_SUBMIT e KBASE_IOCTL_MEM_FLAGS_CHANGE. Em ambiente instrumentado, sinais possíveis incluem: apps não-privilegiados fazendo chamadas ioctl repetidas de alocação/flag-change/free em regiões JIT combinadas com indução artificial de pressão de memória (mmaps grandes seguidos de liberação), crashes ou panics de kernel referenciando funções kbase_jit_* ou kbase_mem_evictable_*, e negações de SELinux/AVC anômalas envolvendo o domínio da GPU. Nenhuma das fontes consultadas descreve IOC ou assinatura EDR publicada para esta CVE especificamente.