OVSwrap: a falha no kernel Linux que dá root a qualquer utilizador — e o exploit já é público

Imagine um servidor Linux em produção — o sistema operativo mais usado do mundo em servidores, o coração de bancos, hospitais e data centers. Agora imagine que qualquer pessoa com uma conta local nesse servidor — um funcionário, um cliente de alojamento partilhado, um atacante que já comprometeu uma aplicação web — consegue tornar-se root, o administrador total da máquina, sem precisar de sudo, sem capacidades especiais e sem que o administrador do sistema tenha feito nada de errado. É exatamente isto que a falha OVSwrap (CVE-2026-64531, pontuação CVSS 7.8) permite no kernel Linux.

A vulnerabilidade foi descoberta e divulgada pelo investigador Asim Manizada a 28 de julho na lista oss-security, com um estudo técnico completo e um exploit funcional público. O bug vive no datapath do Open vSwitch (módulo openvswitch.ko) — a parte do kernel que processa o tráfego de rede virtual — e não no daemon em espaço de utilizador. O Open vSwitch é o componente de rede virtual usado por plataformas como OpenStack, Kubernetes e soluções de virtualização, e está presente na maioria das distribuições Linux modernas.

O que torna OVSwrap tão perigoso

O atacante não precisa de ter um bridge OVS configurado, nem um processo ovs-vswitchd a correr, nem CAP_NET_ADMIN no host. Basta criar um namespace de utilizador e de rede privado com unshare -Urn — uma operação permitida por omissão na maioria das distribuições — para obter capacidades de administração de rede dentro desse namespace isolado. A partir daí, o caminho até ao código vulnerável está aberto. E há um detalhe ainda mais traiçoeiro: se o módulo openvswitch estiver instalado mas não carregado, o próprio kernel carrega-o automaticamente quando o atacante resolve o nome da família Generic Netlink. Um lsmod vazio não significa que o sistema está seguro.

Tecnicamente, o bug é uma falha de validação de tamanho: o campo nla_len usado nos atributos Netlink tem apenas 16 bits, com um limite máximo de 65.535 bytes. O Open vSwitch consegue gerar uma ação aninhada maior do que esse limite — um atacante submete uma ação CLONE cheia de centenas de sub-ações conntrack que, em x86-64, são expandidas para 164 bytes cada, ultrapassando o limite. Quando o valor é escrito no campo de 16 bits, o comprimento 'rebenta' (wrap) e o kernel passa a interpretar dados controlados pelo atacante como instruções legítimas. Manizada descreve o resultado como uma corrupção de memória com "fiabilidade digna de bug lógico" — sem condições de corrida, sem necessidade de heap grooming.

O pinguim Tux, mascote do Linux — o sistema afetado por OVSwrap em quase todas as suas distribuições modernas. Crédito: Wikimedia Commons (CC BY-SA 3.0)

800 builds de kernel no exploit

O exploit público encadeia três primitivas resultantes do wrap: uma fuga de ponteiro de kernel através de uma ação OUTPUT falsa, uma leitura arbitrária de memória de kernel através de uma ação SET de túnel forjada e um decremento direcionado durante o teardown de um ponteiro de destino de túnel. Com estas peças, o atacante localiza as credenciais de um processo do host e, nos kernels modernos, decrementa o fsuid e o fsgid para zero. No final, o exploit corrompe uma credencial viva do kernel, modifica o /etc/sudoers ou /etc/sudoers.d, abre uma shell root — e deixa processos e estado OVS para trás de propósito, para evitar um teardown inseguro que pudesse travar o sistema.

O repositório do PoC inclui registos pré-construídos para cerca de 800 builds exatos de kernel x86-64 e tenta derivação dinâmica a partir de símbolos ou BTF para builds não cobertos. A matriz de testes de Manizada encontrou exploração por omissão em AlmaLinux 9 e 10, Alpine 3.22–3.24, Amazon Linux 2023, Arch, CentOS Stream 9 e 10, Debian 12 e 13, Fedora 42–44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS e openSUSE Tumbleweed. No Ubuntu 24.04, o AppArmor bloqueia a criação direta de namespaces, mas o fallback aa-exec -p trinity do PoC restaura o acesso; no Ubuntu 26.04 standard, a rota de utilizador comum fica bloqueada (desativar a restrição AppArmor torna-o explorável). Sistemas mais antigos como Amazon Linux 2, Debian 11, Rocky Linux 8 e Ubuntu 20.04 não são exploráveis por esta via, por manterem caminhos de código antigos.

Servidores Linux em produção são o alvo típico desta falha — em alojamento partilhado, um único site comprometido pode transformar-se em root no servidor inteiro. Crédito: Wikimedia Commons (CC BY-SA 3.0)

O que fazer agora

A correção upstream já foi enviada para os ramos estáveis do kernel a 24 de julho, antes da divulgação pública: as primeiras versões corrigidas são 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 e 7.1.5 (o commit "net: openvswitch: reject oversized nested action attrs"). Para quem ainda não tem um kernel corrigido do seu fornecedor, existe uma mitigação de uma linha que bloqueia o carregamento do módulo: echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf — preferível a um blacklist simples, que não bloqueia a chamada request_module() que o exploit usa. Esta medida só é segura em servidores que não usam Open vSwitch de verdade (OVN, OpenStack Neutron, alguns plugins de rede Kubernetes). Uma segunda camada de defesa é desativar os namespaces de utilizador sem privilégios (user.max_user_namespaces=0 em muitas distros).

Até agora, não há relatos confirmados de exploração ativa na natureza — mas a combinação de um estudo público, código de exploit funcional e impacto generalizado faz desta uma correção prioritária para qualquer servidor multiutilizador, alojamento partilhado ou host de contentores com um kernel afetado.

— Análise de impacto, pbxscience (4 Ago 2026)

Para o utilizador doméstico de Linux, o risco prático é baixo — a falha exige acesso local à máquina. Mas para quem gere servidores — empresas, alojamento partilhado, instituições públicas — OVSwrap é daquelas falhas que não se pode ignorar: o cenário do site comprometido que se transforma em servidor inteiro comprometido é exatamente o que esta vulnerabilidade permite. Atualizar o kernel (ou aplicar a mitigação de uma linha) é a diferença entre uma conta de alojamento e o controlo total da máquina.