CVE-2023-26083

Falha de vazamento de memória no driver de kernel da GPU Mali (Arm), que permite a um processo local sem privilégios elevados obter metadados de memória do kernel através de operações de GPU consideradas válidas. O CVSS 3.1 é baixo (3.3) porque o impacto é só confidencialidade e exige acesso local, mas a CVE está no catálogo KEV da CISA por ter sido explorada ativamente — documentada em cadeias de exploração de fornecedores comerciais de spyware contra Android, geralmente como peça auxiliar (leak de endereços de kernel) e não como exploit isolado de alto impacto.

CWE-401 (Missing Release of Memory after Effective Lifetime). O driver de kernel da Mali GPU (nas famílias Midgard, Bifrost, Valhall e Avalon) não libera ou zera corretamente regiões de memória do kernel usadas em operações de processamento gráfico antes de devolvê-las ao espaço de usuário. Um processo não privilegiado, ao emitir chamadas legítimas de processamento GPU (via ioctl no driver, tipicamente /dev/mali0 em Android), recebe de volta buffers que ainda contêm dados residuais de estruturas internas do kernel.

O atacante não precisa corromper nada nem forçar um estado inválido — a operação em si é válida do ponto de vista da API do driver; o bug está na ausência de sanitização/liberação de memória entre alocações. O que o atacante controla é a sequência e o timing de chamadas ao driver para maximizar a chance de recuperar dados úteis (endereços de kernel, ponteiros, outros metadados) do heap ou de estruturas reutilizadas.

O CVSS 3.1 (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflete impacto isolado de confidencialidade baixo, sem afetar integridade ou disponibilidade. A versão CVSS v4.0 usada por terceiros (cybersecurity-help) atribui VC:H, indicando que na prática o vazamento pode expor dados de alto valor (como endereços de kernel), o que explica por que essa falha aparece em cadeias de exploração reais mesmo com nota CVSS 3.1 baixa.

Vetor local (AV:L), complexidade de ataque baixa (AC:L), exige privilégio baixo (PR:L) e nenhuma interação do usuário (UI:N). Na prática, o pré-requisito real é ter um processo em execução no dispositivo com acesso ao nó do driver Mali — em Android isso normalmente significa já ter conseguido executar código em um app ou processo com permissões comuns, seja por instalação de app malicioso, seja como estágio pós-exploração de outra vulnerabilidade (ex: um exploit de navegador).

O valor da falha para um atacante é raramente 'ler dados sensíveis' isoladamente — é usá-la como primitiva de leak de informação (por exemplo, obter endereços de kernel) para viabilizar ou facilitar outra etapa de uma cadeia de exploração, como bypass de KASLR ou preparação para uma escrita arbitrária de kernel. É por isso que a Google TAG documentou essa CVE associada a fornecedores comerciais de spyware que combinam 0-days e n-days contra Android.

A presença no catálogo KEV da CISA confirma exploração ativa (adicionada em 2023-04-07, prazo de remediação 2023-04-28 para agências federais dos EUA), mas as fontes disponíveis não detalham o exploit específico nem apontam PoC pública com passo a passo — o registro trata a falha como componente de campanhas de spyware documentadas, não como exploit isolado e trivial de reproduzir.

A ação recomendada pelo fornecedor e pela CISA é aplicar as atualizações do driver conforme o advisory da Arm (Mali GPU Driver Vulnerabilities). As fontes consultadas não trazem o número exato de build/versão corrigida para cada linha (Midgard, Bifrost, Valhall, Avalon) — isso deve ser confirmado diretamente na tabela do advisory oficial da Arm antes de declarar qualquer dispositivo corrigido, já que Arm distribui código-fonte para fabricantes (OEMs) integrarem, e o timing real do patch depende do fabricante do SoC/dispositivo, não da Arm diretamente.

Em dispositivos Android, isso significa que a correção chega via atualização de firmware/kernel do fabricante (não pela Play Store), e o atraso típico desse tipo de patch é um fator relevante de risco — dispositivos mais antigos ou fora do ciclo de suporte do fabricante podem nunca receber o backport.

Não há controle compensatório eficaz a nível de aplicação, já que o acesso é ao driver de kernel; restringir o acesso ao nó de dispositivo GPU (permissões de SELinux/kernel) reduz superfície mas pode quebrar funcionalidade legítima em muitos casos, e não é uma mitigação documentada pelo fornecedor. Não confundir isso com uma correção — na ausência de patch, a exposição permanece.

Não há assinatura de rede ou log de aplicação confiável para detectar exploração, já que o vetor é local e a interação com o driver ocorre via chamadas de API/ioctl legítimas do subsistema GPU — o mesmo tipo de chamada usado por aplicações gráficas normais. Em nível de kernel/EDR móvel, sequências anômalas de chamadas ao driver Mali por processos sem histórico de uso intensivo de GPU, ou por processos recém-instalados com privilégios elevados de acesso a /dev/mali0, podem ser um indicador indireto, mas nenhuma das fontes consultadas documenta um IOC específico ou padrão de exploração conhecido publicamente.