CVE-2013-2596

Integer overflow na função fb_mmap() do subsystem de framebuffer do kernel Linux (drivers/video/fbmem.c), presente em versões anteriores à 3.8.9. Um usuário local com acesso ao device node de framebuffer (ex: /dev/graphics/fb0, /dev/fb0) pode forjar o offset passado numa syscall mmap2 para burlar o cálculo de limites e obter um mapeamento read-write cobrindo memória física arbitrária — incluindo estruturas do kernel — o que se traduz em escalação de privilégios local. Ganhou notoriedade por ser a base do exploit 'Motochopper', usado para rootear aparelhos Motorola com Android 4.1.2, e está no catálogo KEV da CISA por exploração confirmada.

O bug é um CWE-190 (integer overflow) na lógica original de fb_mmap(). O código calculava off = vma->vm_pgoff << PAGE_SHIFT a partir de um valor de pgoff totalmente controlado pelo processo que chama mmap2() sobre o device de framebuffer, e depois validava os limites com uma expressão do tipo (vma->vm_end - vma->vm_start + off) > len antes de somar off ao endereço físico base (start) do framebuffer e chamar io_remap_pfn_range(). Como off é derivado de um deslocamento de página shiftado à esquerda, um pgoff grande o suficiente faz a soma estourar o tipo unsigned long, contornando a checagem de limite que deveria impedir mapear além do tamanho real do framebuffer.

O efeito prático do overflow é duplo: a verificação de tamanho passa mesmo com um range fora dos limites do framebuffer, e o endereço físico final (start + off) também pode dar wrap, resultando em um pfn base arbitrário — potencialmente próximo de zero, cobrindo memória física de baixo endereço onde residem estruturas do kernel. O kernel então mapeia essa região como leitura/escrita direta no espaço de endereçamento do processo chamador via io_remap_pfn_range(), sem qualquer controle de acesso adicional (mmio/mmap normalmente não passa por checagens de capacidade granular além da permissão no device node).

A correção structural veio em duas partes: o commit b4cbb197c7e7 introduziu o helper genérico vm_iomap_memory(), que centraliza e valida corretamente overflow em start+len e pfn+pages antes de qualquer remapeamento; o commit fc9bbca8f650 reescreveu fb_mmap() para usar esse helper em vez de fazer a aritmética de offset manualmente. O padrão de bug (checagem de limites feita depois de uma soma que pode overflow) também apareceu em outros drivers que faziam mmap direto de memória física (bsr, hpet, mtdchar), o que motivou a limpeza generalizada anunciada por Linus Torvalds na lista linux-kernel.

O pré-requisito real é acesso local ao node de device do framebuffer (tipicamente /dev/graphics/fb0 no Android ou /dev/fb0 em Linux genérico). Em builds Android da época, esse device costumava ser acessível ao usuário shell/adb ou a apps com grupo 'graphics', o que tornava a exploração viável sem root prévio — daí o vetor PR:L do CVSS (algum nível de privilégio/acesso é necessário, mas não root). Não há componente de rede: é um exploit puramente local via syscall mmap2 sobre um file descriptor aberto no device de framebuffer.

A exploração consiste em abrir o device e chamar mmap2 com um valor de offset (pgoff) calculado para provocar o overflow na checagem de limites de fb_mmap(), obtendo de volta um mapeamento de memória que na prática cobre regiões de memória física do kernel com permissão de leitura e escrita. A partir desse mapeamento, o atacante lê e escreve diretamente em estruturas de kernel em memória — o vetor clássico usado por 'Motochopper' era localizar e sobrescrever credenciais de processo (ou estruturas equivalentes) para elevar o processo atual a UID 0, obtendo root completo no dispositivo.

Há exploração ativa e confirmada — a falha está no catálogo KEV da CISA e existe PoC pública (o próprio Motochopper, distribuído como ferramenta de root para aparelhos Motorola). A complexidade é baixa: não exige corrida de condição, heap grooming ou bypass de ASLR/KASLR sofisticado, já que o próprio mapeamento entrega acesso direto de leitura/escrita à memória física — típico de kernels de 2012-2013 sem essas mitigações amplamente habilitadas em builds mobile.

A correção definitiva é atualizar para kernel Linux 3.8.9 ou posterior (mainline), ou para uma versão de distribuição/vendor que tenha incorporado os commits b4cbb197c7e7 (vm_iomap_memory) e fc9bbca8f650 (fb_mmap convertido para usar o helper). Para RHEL, a Red Hat publicou correção via RHSA-2015:0695 (RHEL Server AUS 6.2) e também RHSA-2015:0782 e RHSA-2015:0803 para outros ramos/kernels afetados — aplique o kernel corrigido correspondente à sua versão de RHEL.

Onde atualização de kernel não é viável no curto prazo (comum em dispositivos Android descontinuados sem atualização de firmware do fabricante), o controle compensatório real é restringir o acesso ao device node do framebuffer: remover permissões de leitura/escrita para usuários e grupos não essenciais em /dev/graphics/fb0 ou /dev/fb0, e garantir que apps de terceiros e o usuário shell/adb não tenham acesso direto a esse device. Isso não corrige a falha no kernel, mas elimina o vetor de exploração ao negar o pré-requisito de acesso ao arquivo.

Não existe mitigação via WAF ou controle de rede, porque a falha é 100% local e não passa por nenhuma superfície de rede. Políticas de MAC (SELinux/AppArmor) que restrinjam contextos de acesso ao device de framebuffer reduzem a superfície, mas em builds Android da época o enforcement de SELinux para esse device era frequentemente permissivo ou ausente — não assuma que SELinux 'enforcing' genérico neutraliza o vetor sem verificar a política específica.

Não há assinatura de rede, já que a exploração é puramente local via syscall mmap2 sobre um device de framebuffer. Em endpoints/dispositivos móveis, o sinal mais confiável é comportamental: presença de binários conhecidos de root (como o próprio 'Motochopper' ou ferramentas de rooting que o empacotam), processos abrindo /dev/graphics/fb0 ou /dev/fb0 fora do contexto esperado (fora do compositor gráfico/driver de vídeo legítimo), ou mudanças inesperadas de UID/GID em processos de terceiros. Auditoria de syscalls (auditd com regra em mmap2 sobre os device nodes de framebuffer) pode registrar tentativas, mas não é uma configuração padrão em builds Android da época — na prática, detecção retroativa depende de análise forense do binário do exploit ou de indicadores de comprometimento (arquivos, hashes) associados ao Motochopper, não de um padrão de tráfego ou log nativo confiável.