Double Free in net/packet/af_packet.c leading to priviledge escalation

Falha de double free em packet_set_ring(), no subsistema de packet sockets (AF_PACKET) do kernel Linux. Um usuário local com capability CAP_NET_RAW — que não exige ser root, inclusive dentro de user namespaces não privilegiados — pode acionar a falha via chamadas de socket manipuladas para corromper memória do kernel, causando DoS ou escalonamento de privilégios. Está no catálogo KEV da CISA com exploração confirmada e PoC pública, o que eleva sua prioridade prática além do que o CVSS 6.6 sugere.

O bug (CWE-415, double free) está em packet_set_ring(), em net/packet/af_packet.c. A função gerencia a criação e destruição do packet ring (pg_vec) usado por PACKET_RX_RING/PACKET_TX_RING, e desde o commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") passou a alocar também um bitmap auxiliar, rx_owner_map, usado para rastrear posse de buffers no modo TPACKET_V3.

O problema é que rx_owner_map e outros campos usados por versões diferentes do ring (v1/v2 vs v3) compartilham uma union na estrutura interna. O código de erro em packet_set_ring() chamava bitmap_free(rx_owner_map) incondicionalmente, mesmo quando pg_vec era NULL — ou seja, quando nenhum packet ring novo tinha sido efetivamente alocado nesta chamada. Nesse caso, o conteúdo do campo que o código interpretava como rx_owner_map podia ser, na verdade, estado remanescente de uma configuração anterior de TPACKET_V3 armazenado no mesmo espaço de memória via union. O kernel liberava esse ponteiro tratando-o como o bitmap válido, e mais adiante o liberava de novo pelo caminho normal — o double free.

O atacante controla, via setsockopt() com PACKET_RX_RING/PACKET_TX_RING, a sequência de trocas entre versões do packet ring (TPACKET_V1/V2 para TPACKET_V3 e vice-versa) e os parâmetros de tp_block_nr/tp_block_size que definem o layout do ring. É essa manipulação de estado entre versões, sem realocar de fato o pg_vec, que expõe o campo compartilhado da union em estado inconsistente.

A correção (commit ec6af094ea28f0f2dda1a6a33b14cd57e36a9755, de Willem de Bruijn, dez/2021) move a chamada bitmap_free(rx_owner_map) para dentro do bloco condicional que só executa quando pg_vec não é NULL — alinhando a liberação do bitmap ao mesmo ciclo de vida do packet ring, e evitando interpretar estado de uma versão de ring diferente. O bug foi encontrado pelo syzbot (fuzzer de kernel do Google).

Pré-requisito real, e o ponto mais importante da página: o atacante precisa de CAP_NET_RAW, não necessariamente de root. Essa capability é frequentemente concedida em contêineres, sandboxes e user namespaces não privilegiados para permitir criação de raw sockets — é exatamente esse cenário que os advisories de distro apontam ("um usuário local com CAP_NET_RAW, em qualquer user namespace"). Isso amplia significativamente a superfície real de exploração em relação ao que a manchete "privilege escalation" sugere isoladamente: ambientes multiusuário com contêineres não confiáveis, CI/CD compartilhado ou sandboxes de execução são o alvo típico, não uma máquina single-user tradicional.

A exploração ocorre inteiramente via syscalls locais: criação de um socket AF_PACKET e chamadas de setsockopt() para configurar e reconfigurar o ring de recepção/transmissão alternando entre versões do protocolo (TPACKET_V1/V2 e TPACKET_V3), de forma a atingir o caminho de erro em packet_set_ring() com pg_vec NULL enquanto ainda existe estado de rx_owner_map de uma configuração anterior. O CVSS marca AC:H (alta complexidade) e UI:R (interação do usuário) — reflexo de que acionar a condição de corrida/estado exige uma sequência específica de chamadas, não é um one-shot trivial.

Uma vez desencadeado, o double free corrompe a memória do heap do kernel. Na prática isso é usado primeiro para negação de serviço (pânico do kernel); escalonamento de privilégios exige técnicas adicionais de heap grooming para reaproveitar a memória liberada duas vezes de forma controlada — o próprio texto do fornecedor reconhece isso como possível, não garantido. A entrada no KEV da CISA confirma exploração ativa, mas não detalha se o uso observado foi para DoS, escalonamento, ou ambos.

A correção definitiva é atualizar para um kernel que já inclua o commit ec6af094ea28f0f2dda1a6a33b14cd57e36a9755 (mainline, aplicado em 15/12/2021) ou o backport equivalente da distribuição usada. Para Debian, isso significa linux-4.19 versão 4.19.232-1~deb9u1 ou posterior no ramo LTS (DLA-2941-1), e a versão corrigida do pacote linux distribuída via DSA-5096-1 no Debian estável — os números exatos de outras distros/branches não constam nas fontes consultadas aqui; confirme a versão específica do seu pacote antes de considerar corrigido.

Se não for possível atualizar imediatamente, o controle compensatório real é restringir quem obtém CAP_NET_RAW: remover a capability de contêineres e cargas de trabalho que não precisem de raw sockets, bloquear socket(AF_PACKET, ...) e as chamadas setsockopt(SOL_PACKET, PACKET_RX_RING/PACKET_TX_RING, ...) via seccomp para processos não confiáveis, e revisar configurações de user namespace não privilegiado que concedem essa capability por padrão. Esse paliativo tem custo funcional: quebra ferramentas legítimas que dependem de raw sockets (captura de pacotes, alguns daemons de rede, certas cargas de contêiner), então precisa ser aplicado com escopo — por usuário, cgroup ou perfil seccomp — em vez de globalmente.

O que não funciona como mitigação: assumir que só root é afetado. A própria descrição do fornecedor e os advisories de distro deixam explícito que CAP_NET_RAW basta, e essa capability circula em ambientes não-root com frequência maior do que se imagina, especialmente em plataformas de contêineres.

Não há assinatura de rede confiável para detectar exploração, porque o vetor é inteiramente local (syscalls socket()/setsockopt() em AF_PACKET). Em auditoria de host, sinais possíveis incluem: mensagens de kernel de double free/corrupção de heap relacionadas a af_packet, bitmap_free ou free_pg_vec (via dmesg, KASAN se habilitado, ou crash dumps); uso de auditd/seccomp-notify para registrar processos não privilegiados chamando setsockopt(SOL_PACKET, PACKET_RX_RING/PACKET_TX_RING, ...) alternando versões de protocolo repetidamente; e correlação com processos que possuem CAP_NET_RAW fora do esperado (contêineres, sandboxes). Na ausência de KASAN ou logging de auditoria de syscall detalhado, um double free bem-sucedido pode se manifestar apenas como pânico ou instabilidade do kernel sem rastro específico anterior — trate essa falta de sinal como informação relevante ao avaliar exposição.