Nova vulnerabilidade no OVSwrap para Linux concede privilégios de root a usuários locais em sistemas com configuração padrão

A versão resumida

Ir para a versão completa ↓

O que é: CVE-2026-64531, também conhecido como OVSwrap, é uma vulnerabilidade de escalonamento de privilégios locais no kernel do Linux, localizada no caminho de validação de ações do Open vSwitch. Um campo de comprimento de 16 bits sofre um deslocamento quando o kernel constrói uma ação aninhada com tamanho excessivo, e o analisador retoma a leitura dentro de bytes controlados pelo invasor, que são então processados como ações legítimas do Open vSwitch. Ir para esta seção →

Impacto: Um usuário local comum pode vazar ponteiros do kernel, ler a memória do kernel e realizar uma gravação direcionada. A prova de conceito pública encadeia essas ações em um caminho completo de corrupção de credenciais que grava uma entrada no arquivo `sudoers` e abre um shell como root. Ela vem com offsets pré-calculados para aproximadamente 800 compilações do kernel x86-64. Ir para esta seção →

Gravidade: Com uma pontuação de gravidade de 7,8, trate isso como alta prioridade. A exploração requer apenas uma conta local normal e nada mais: sem configuração do Open vSwitch, sem o ovs-vswitchd em execução, sem ponte OVS, sem CAP_NET_ADMIN no namespace inicial, sem contêiner privilegiado. O comando `unshare -Urn` fornece a capacidade dentro de um namespace criado pelo invasor. Ir para esta seção →

Quem é afetado: Qualquer kernel afetado em que os namespaces de usuários sem privilégios sejam permitidos e o módulo openvswitch esteja disponível para carregamento. Essa é a configuração padrão na maioria das distribuições. Escopo confirmado por nossa própria análise de backport: Enterprise Linux 9.7 e versões posteriores, Enterprise Linux 10.1 e versões posteriores, Debian 12 e 13, Ubuntu 22.04 e 24.04 e Amazon Linux 2023. Ir para esta seção →

Status: Não se trata de uma vulnerabilidade “zero-day”. Foi relatada de forma privada em 19 de junho de 2026 e corrigida nos ramos estáveis em 24 de julho. O registro CVE e o anúncio do CVE para Linux foram divulgados em 27 de julho, seguidos pelo relatório completo e por um exploit funcional em 28 de julho. Não há relatos públicos de exploração em ambiente real. Ir para esta seção →

Faça isso agora: aplique um kernel de fornecedor fixo e reinicie o sistema, ou implante o patch ao vivo do KernelCare sem necessidade de reinicialização (que já foi implantado automaticamente para usuários de várias distribuições). Se o host não usar o Open vSwitch, bloqueie o módulo enquanto isso. Uma coisa a ser ignorada: o apparmor_restrict_unprivileged_userns e as configurações de fortalecimento relacionadas do userns no Debian e no Ubuntu não impedem essa cadeia. Nossa equipe de kernel testou essas configurações. Ir para esta seção →

Verificar se o módulo está carregado não é o teste correto. Verifique se ele está presente no disco para o kernel em execução:

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

Se isso exibir um caminho, o host ficará exposto até que o kernel seja corrigido ou o módulo seja bloqueado, independentemente de já ter sido carregado ou não.

A maioria dos servidores expostos ao OVSwrap nunca executou o Open vSwitch conscientemente. É isso que pega as equipes de surpresa.

O OVS é amplamente associado às redes definidas por software: OpenStack, OVN, CNIs do Kubernetes, plataformas de virtualização. Se nada disso estiver presente em sua pilha de tecnologias, é razoável supor que essa CVE não se aplique. No entanto, o código vulnerável é fornecido como um módulo carregável no pacote padrão do kernel em praticamente todas as distribuições mais comuns, e o kernel o carrega sob demanda quando algo o solicita.

Um usuário sem privilégios solicita isso. Ele cria um espaço de nomes privado para usuário e rede, que concede o CAP_NET_ADMIN dentro desse espaço de nomes, e isso é suficiente para instalar os fluxos do Open vSwitch por meio da interface Netlink. A solicitação carrega automaticamente o módulo no kernel do host. Sem decisão do administrador, sem arquivo de configuração, sem daemon.

Portanto, “não utilizamos o Open vSwitch” não é uma afirmação sobre exposição. É uma afirmação sobre se o bloqueio do módulo causará algum problema, o que é uma questão diferente e mais útil.

O momento em que isso ocorreu é outro ponto a ser observado. O commit 3f1f75536668 do upstream chegou à versão estável quatro dias antes de a vulnerabilidade ser divulgada publicamente; portanto, as frotas que utilizam ciclos rápidos de atualização do kernel estável podem já estar protegidas. Quatro dias também representam todo o intervalo entre o momento em que a “correção estava disponível” e o momento em que surgiu uma “vulnerabilidade funcional com offsets para 800 compilações”.

As ações do Open vSwitch são transportadas como atributos Netlink. Cada uma delas começa com um cabeçalho `struct nlattr` que contém um campo `nla_len` de 16 bits, o qual pode representar, no máximo, 65.535 bytes.

Quando o OVS valida um fluxo, ele expande as ações aninhadas em um fluxo de ações interno gerado pelo próprio kernel. OVS_ACTION_ATTR_CLONE é o que importa neste caso, pois ele envolve outra lista de ações e, portanto, pode ser aninhado. O código vulnerável nunca verificou se um atributo aninhado gerado ainda cabia dentro do campo de comprimento de 16 bits.

[Attacker enters a private user and network namespace]
|
v
[Attacker gains CAP_NET_ADMIN inside that namespace]
|
v
[Attacker installs a flow packing hundreds of conntrack
actions inside a CLONE wrapper]
|
v
[Generated nested action stream exceeds 65,535 bytes]
|
v
[Length is stored in the 16-bit nla_len field and wraps
to a small value]
|
v
[Parser resumes mid-stream, inside attacker-controlled data]
|
v
[Forged action headers are parsed as real OVS actions]
|
v
[Kernel read and constrained write primitives]
|
v
[Host-process credentials corrupted, root shell]

A exploração agrupa centenas de ações conntrack dentro de um invólucro CLONE. À medida que o OVS as expande, o fluxo gerado ultrapassa a capacidade do nla_len; o valor é truncado e volta a um valor menor, e o analisador para no deslocamento errado. Ele retoma a análise no meio do fluxo, em bytes escolhidos pelo invasor, organizados de forma a parecerem cabeçalhos de ação válidos. O kernel os processa como ações genuínas.

Os requisitos de acessibilidade são os únicos limites reais: x86-64, um caminho de dados do kernel OVS com suporte a conntrack e FTP-helper disponível e permissão para a criação de namespaces sem privilégios. Um kernel de distribuição x86-64 padrão, com contêineres sem root habilitados, atende a todos os três requisitos.

As ações criadas são a origem das primitivas.

Ações SET em túneis falsos causam um vazamento de ponteiro do kernel e uma leitura de memória do kernel. Um caminho separado de limpeza do destino do túnel resulta em uma gravação restrita, na forma de um decremento direcionado da contagem de referências de 32 bits.

Um único decremento de 32 bits parece fraco demais para fazer diferença e, por si só, realmente é. É a configuração em torno dele que o torna suficiente. Antes de entrar no namespace, a exploração cria um processo filho que permanece no lado do host. Em seguida, direciona o decremento às credenciais desse processo e, assim que o processo obtém privilégios, grava uma entrada na configuração do sudoers e inicia um shell como root.

O resultado é uma escalação de privilégios confiável, em vez de uma falha no sistema. Combinado com deslocamentos pré-calculados para cerca de 800 compilações do kernel, o trabalho necessário para reproduzir isso em um alvo compatível é praticamente nulo.

Duas condições determinam se um host pode ser explorado, e ambas são padrões em praticamente todos os lugares: os namespaces de usuários sem privilégios são permitidos, e o openvswitch faz parte do pacote padrão do kernel, sem nenhuma restrição de carregamento automático. As distribuições mantêm os namespaces habilitados porque o Podman sem privilégios de root, o Docker sem privilégios de root, o Bubblewrap, o Flatpak, o comando unshare(1) sem privilégios e a sandbox do Chromium dependem deles.

O ataque divulgado não requer:

• Um processo ovs-vswitchd em execução
• Uma ponte Open vSwitch já existente
• Qualquer configuração anterior do Open vSwitch
• CAP_NET_ADMIN no namespace do host
• Um contêiner privilegiado
• O módulo a ser carregado antes do início do ataque

Isso significa que a superfície de ataque é mais ampla do que nos hosts que executam ativamente o OVS: ela inclui sistemas afetados nos quais o módulo está simplesmente disponível para ser acionado por um usuário sem privilégios, e os testes realizados pelo pesquisador revelaram que essa situação se aplica à maioria das distribuições testadas em sua configuração padrão.

Imagine como isso funciona. Um executor de compilação compartilhado que executa tudo o que foi enviado na última solicitação de fusão. Um nó multilocatário onde o código do cliente é executado em uma conta comum. Uma estação de trabalho de desenvolvedor com contêineres sem acesso root e algumas centenas de dependências que ninguém leu. Em cada um desses casos, o invasor já possui a conta local, e o módulo de que precisa está a apenas uma solicitação Netlink de ser carregado.

A decisão para cada anfitrião é breve:

• Se o host não utilizar o OVS e nada nele depender de pontes baseadas no OVS, bloqueie o módulo. Isso remove o caminho de código vulnerável, em vez de bloquear apenas uma rota de acesso a ele.
• Se o host utilizar o OVS — seja um nó OVN ou OpenStack Neutron, um cluster do Kubernetes executando o ovn-kubernetes ou o Antrea, ou um host libvirt ou oVirt com pontes baseadas no OVS —, não altere o módulo. Em vez disso, recuse os namespaces de usuários sem privilégios ou aplique o patch.

A falha é antiga, mas a janela de vulnerabilidade não é

Há duas datas importantes, e confundir uma com a outra leva a uma resposta errada na triagem.

A atribuição insegura ao campo de comprimento de 16 bits existe há cerca de 13 anos. Durante a maior parte desse tempo, um limite condicional separado restringia o fluxo de ações gerado a 32 KiB, o que impedia que uma ação se tornasse grande o suficiente para ultrapassar o valor de nla_len. O limite foi removido em março de 2025, e foi isso que tornou o bug latente acessível.

Em termos da linha principal, a janela de vulnerabilidade se estende até o Linux 6.14. Os ramos de longo prazo mais antigos tornaram-se vulneráveis quando a remoção do limite foi retroaplicada a eles, e não quando o bug original foi criado.

Intervalos de estabilidade divulgados publicamente:

• 5.15.180 a 5.15.211
• 6.1.132 a 6.1.177
• 6.6.84 a 6.6.144
• 6.18.0 a 6.18.39
• 7.1.0 a 7.1.4

Versões com as primeiras correções relatadas: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 e 7.1.5.

Os kernels de fornecedores divergem do upstream em ambas as direções; portanto, os intervalos acima são um ponto de partida, e não uma resposta definitiva. Alguns kernels 5.14 derivados do RHEL incorporam a alteração de habilitação e são afetados, apesar de se situarem abaixo de todos os intervalos da tabela. Alguns kernels 6.12 da SUSE mantiveram o limite antigo e não são afetados, apesar de se situarem dentro de um desses intervalos.

As distribuições empresariais também fazem o backport de commits individuais sem adotar uma versão do upstream; portanto, um kernel cuja versão esteja fora da janela publicada ainda pode conter a combinação vulnerável. A janela foi introduzida diretamente na linha de desenvolvimento 6.14 e, posteriormente, estendida a ramos mais antigos de suporte de longo prazo à medida que essa alteração foi incorporada a eles. Verifique o comunicado ou o status do patch para o kernel específico da distribuição.

O commit a1e64addf3ff, “net: openvswitch: remoção da verificação de comprimento de ações com comportamento irregular”, removeu esse limite em março de 2025, pois ele estava causando falhas imprevisíveis, já que as ações do OVS podem aumentar ou diminuir de tamanho à medida que são convertidas para seu formato interno. A remoção da verificação de comprimento total foi uma decisão razoável. O efeito colateral foi que nada impedia que um atributo aninhado individual ultrapassasse 65.535 bytes.

Nossa análise do kernel confirmou a vulnerabilidade nessas famílias de plataformas compatíveis:

• Enterprise Linux 9.7 e versões posteriores
• Enterprise Linux 10.1 e versões posteriores
• Debian 12 (apenas as versões 6.1.132-1 e posteriores) e Debian 13
• Ubuntu 22.04 LTS e Ubuntu 24.04 LTS
• Amazon Linux 2023

O escopo do Enterprise Linux abrange os kernels correspondentes do RHEL, AlmaLinux, Rocky Linux e CloudLinux, nos quais o código afetado é compartilhado. O CloudLinux 9 utiliza o kernel do AlmaLinux 9 e o CloudLinux 10 utiliza o kernel do AlmaLinux 10; portanto, ambos estão diretamente expostos à vulnerabilidade.

A cobertura é específica para cada versão e variante. Não se deve inferir que uma variante adjacente esteja vulnerável ou já tenha sido corrigida apenas porque outra versão da mesma distribuição aparece na lista.

Duas questões ainda permanecem em aberto, sem uma resposta clara. O Enterprise Linux 8 e o CloudLinux 8 — que utilizam uma linha de kernel própria, distinta da do AlmaLinux 8 — ainda não tiveram sua situação confirmada, assim como o Ubuntu 20.04 e as versões mais antigas de longo prazo do Debian e do Ubuntu. A dúvida em relação a todas elas é se adotaram o retroportamento da remoção do limite.

Uma suposição sobre o fortalecimento de segurança que deve ser descartada logo de início: o pesquisador relata que nem o SELinux nem o AppArmor bloquearam nenhuma etapa da exploração durante os testes, exceto pela política de namespace do usuário do AppArmor, que bloqueou a criação de namespaces em algumas versões do Ubuntu — o que será abordado a seguir. O modo de imposição não altera o resultado neste caso.

Por que as restrições comuns ao namespace do usuário podem não ajudar

Essa é a parte que tem mais chances de fazer alguém perder o fim de semana.

As versões recentes do Ubuntu vêm com uma política do AppArmor que restringe a criação de namespaces por usuários sem privilégios, controlada pela variável kernel.apparmor_restrict_unprivileged_userns. Essa é a primeira opção que a maioria das equipes utiliza, e ela realmente bloqueia a rota simples `unshare -Urn`: no Ubuntu 24.04 e 26.04, a tentativa direta falha com a política padrão em vigor.

Essa não é uma medida de mitigação na qual você deva confiar. Uma forma de contornar o AppArmor, documentada publicamente, anula a política na versão 24.04, e na versão 26.04 a exploração funciona assim que a restrição é desativada. Nossa própria equipe de kernel chegou ao caminho vulnerável mesmo com os recursos de fortalecimento do Debian e do Ubuntu ativados. Trate a política como um obstáculo temporário até que um patch seja lançado.

Negar categoricamente a criação de um namespace de fato rompe a cadeia publicada, pois o invasor não consegue mais acessar CAP_NET_ADMIN por meio do comando `unshare -Urn`. O controle responsável por isso é o de nível superior:

# /etc/sysctl.d/99-ovswrap.conf
user.max_user_namespaces = 0

sudo sysctl --system

Utilize user.max_user_namespaces em vez de kernel.unprivileged_userns_clone. Este último é um patch derivado da família Debian, considerado obsoleto, que não existe no Enterprise Linux; já no Ubuntu, onde ambos podem estar presentes, definir apenas o parâmetro unprivileged_userns_clone pode deixar um caminho residual para a criação de namespaces, dependendo da versão do kernel.

Verifique o valor efetivamente adotado, pois um arquivo de distribuição em /usr/lib/sysctl.d/ que for executado posteriormente terá prioridade sem aviso prévio:

sysctl user.max_user_namespaces

O custo da compatibilidade é real. As ferramentas de contêineres sem root deixam de funcionar, o comando `unshare(1)` sem privilégios deixa de funcionar e a sandbox do Chromium deixa de funcionar. Em um ambiente convencional de hospedagem ou em um conjunto de bancos de dados, ninguém percebe. Nas estações de trabalho dos desenvolvedores e nos hosts de compilação de contêineres, percebe-se isso em questão de minutos.

Existe alguma solução alternativa?

A medida de mitigação temporária adequada depende do fato de o host realmente utilizar o Open vSwitch. Nenhuma das opções substitui a correção.

1. Bloqueie o módulo Open vSwitch. Recomendado em qualquer host que não utilize o OVS, o que se aplica à maioria das frotas de hospedagem. Verifique primeiro com o comando `lsmod | grep openvswitch` e confirme se o processo `ovs-vswitchd` não está em execução. Em seguida:

# /etc/modprobe.d/99-ovswrap.conf
blacklist openvswitch
install openvswitch /bin/false

A linha de instalação é a que realiza o trabalho. Uma entrada na lista negra, por si só, não impede a solicitação de módulos sob demanda feita pelo próprio kernel, que é exatamente a via utilizada por essa vulnerabilidade; portanto, a inclusão na lista negra, por si só, não constitui uma medida de mitigação neste caso. Observe que o usuário root ainda pode anular uma diretiva de instalação com o comando `modprobe –ignore-install`, e que os módulos forçados a serem carregados por meio do initramfs não estão sujeitos a nenhuma das duas diretivas.

A regra bloqueia apenas carregamentos futuros. Se o módulo já estiver na memória, interrompa tudo o que dependa dele e descarregue-o, o que também não requer reinicialização:

sudo modprobe -r openvswitch

O arquivo do módulo permanece no disco e o comando `modinfo openvswitch` continua retornando resultados depois disso. Isso é esperado. A regra deixa de ser carregada; ela não exclui nada.

Não aplique isso em nós de computação e de rede do OVN ou do OpenStack Neutron, em clusters do Kubernetes que utilizem o ovn-kubernetes ou o Antrea, nem em hosts libvirt e oVirt com pontes baseadas em OVS. Bloquear o módulo nesses ambientes prejudicará o funcionamento da rede.

2. Negue os namespaces de usuário sem privilégios. Use o parâmetro sysctl `user.max_user_namespaces` mencionado acima. Ele funciona independentemente do estado do módulo, o que o torna a opção alternativa para hosts que realmente executam o OVS, ao custo da falha nas ferramentas do `rootless` já descrita. Teste-o primeiro com suas cargas de trabalho.
3. Trate com cuidado a proteção BPF de terceiros. O repositório público de exploits inclui uma proteção de emergência baseada em BPF. Nós não a testamos. Analise-a e valide-a em sistemas representativos antes de utilizá-la em produção, e não a considere equivalente a uma correção do fornecedor.

Após aplicar a correção, remova a restrição de namespace caso ela não seja mais necessária:

sudo rm -f /etc/sysctl.d/99-ovswrap.conf

O bloco do módulo pode permanecer. Ele não está vinculado a uma versão do kernel, resiste a atualizações e reinicializações e, em um host que não utiliza o Open vSwitch, mantém uma parte da superfície de ataque protegida. Documente-o para que a próxima pessoa saiba por que a rede falha caso esse host venha a precisar do OVS e, nesse caso, remova-o com o comando rm /etc/modprobe.d/99-ovswrap.conf.

A correção no upstream é o commit 3f1f75536668, “net: openvswitch: rejeitar atributos de ação aninhados com tamanho excessivo”.

Ele adiciona uma validação que rejeita uma ação aninhada gerada cujo tamanho não possa ser representado com segurança em nla_len. Em vez de permitir que um valor excessivamente grande seja truncado para 16 bits, o kernel interrompe a ação inválida durante a validação, antes que o fluxo malformado chegue ao caminho de dados.

A alteração ocorre no caminho de validação, e não no caminho rápido do fluxo de dados. Ela não requer migração da estrutura de dados do kernel nem estado persistente por tarefa, o que a torna adequada para a aplicação de patches sem reinicialização.

Aplicar o patch e verificar o kernel em execução

A instalação de um pacote de kernel atualizado não aplica o patch ao kernel em execução na memória. Para uma atualização convencional: instale o pacote corrigido específico para sua distribuição e versão, reinicie o sistema e confirme se o kernel corrigido está em execução.

uname -r

Compare isso com o aviso do fornecedor aplicável, e não com o pacote mais recente no disco. E não presuma que um kernel compilado após 24 de julho de 2026 já inclua a correção. Os números de versão das distribuições não correspondem às versões do código-fonte original; a vulnerabilidade chegou a esses ramos por meio de um backport, e a correção foi incorporada nesses ramos em prazos distintos.

Aplicação de patches sem reinicialização

O KernelCare aplica a mesma lógica de validação do upstream ao kernel ativo. Uma vez corrigido, o OVS rejeita ações aninhadas geradas com tamanho excessivo antes que o comprimento possa ultrapassar o limite, sem a necessidade de desativar o Open vSwitch, alterar a política do módulo ou reiniciar a carga de trabalho. Trata-se de um bug exclusivamente do kernel, sem nenhum componente de biblioteca do espaço do usuário a ser investigado.

A maioria das implantações obtém novos patches automaticamente em segundo plano, em um intervalo definido, geralmente a cada quatro horas. Para baixar sob demanda a partir do feed de produção:

kcarectl --update

Caso um patch ainda esteja em fase de testes para a sua família de kernels:

kcarectl --update --prefix test

Em seguida, verifique se o CVE consta nas informações do patch instalado:

kcarectl --patch-info | grep 'CVE-2026-64531'

Confirme se o patch está disponível para o kernel em execução específico antes de remover qualquer medida de mitigação temporária. Se a cobertura ainda não tiver sido implementada para a sua família, mantenha o bloqueio do módulo ou a restrição de namespace em vigor.

Detecção e análise de incidentes

Não há um único indicador definitivo; portanto, considere tudo o que está aqui como uma pista, e não como uma prova.

O sinal mais útil é o próprio módulo. Em um host que não tenha uso legítimo para o Open vSwitch, o fato de o “openvswitch” aparecer no comando `lsmod` já é, por si só, uma anomalia, e vale a pena investigar os registros de auditoria de carregamento de módulos ou as entradas no diário relacionadas a ele. Esse sinal desaparece assim que você implementar o bloqueio do `modprobe`; portanto, verifique antes de aplicá-lo.

Em seguida, verifique o que o PoC publicado faz com seu acesso de root:

sudo stat /etc/sudoers /etc/passwd /etc/shadow
sudo find /etc/sudoers.d -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n'

Entradas inesperadas no arquivo `sudoers` ou novos arquivos na pasta `/etc/sudoers.d/` são resquícios da prova de conceito publicada; no entanto, um invasor com privilégios de root poderia ignorar essa etapa por completo. Verifique também se há contas novas ou que tenham adquirido privilégios recentemente, chaves SSH inexplicáveis e ganhos de privilégios sem nenhum evento correspondente no `sudo`, no login ou na autenticação, já que credenciais corrompidas por meio de uma gravação no kernel não deixam rastros de autenticação.

Outras pistas comportamentais: processos sem privilégios criando espaços de nomes de usuário e de rede, quando normalmente nenhuma carga de trabalho faz isso; um processo em execução com credenciais de root que não foi iniciado como root e não possui ascendência setuid; e avisos do kernel ou erros “oops” provenientes do caminho de validação de fluxo do OVS, que podem ser gerados por tentativas malsucedidas.

Ainda não reproduzimos internamente a demonstração de conceito (PoC) pública em ambientes restritos ou em contêineres; portanto, não presuma que o isolamento por usuário ou por contêiner seja suficiente para conter a vulnerabilidade sem testar essa rota de chamada de sistema em sua própria configuração.

Não. A vulnerabilidade foi relatada de forma confidencial em 19 de junho de 2026; a correção chegou aos ramos estáveis em 24 de julho, sob um embargo coordenado; e o artigo e a demonstração de conceito (PoC) foram publicados em 28 de julho. Nada na divulgação indica que a vulnerabilidade tenha sido explorada na prática antes da existência de uma correção.

Isso não significa que seja uma prioridade baixa. Assim que a vulnerabilidade veio a público, os invasores receberam um caminho comprovado para obter privilégios de root a partir de uma conta local comum, além de offsets para uma ampla coleção de compilações do kernel. Uma vantagem inicial de quatro dias só ajuda as frotas que já estavam aplicando patches rapidamente nos kernels estáveis.

Por que a vulnerabilidade CVE-2026-64531 é importante

Três detalhes fazem com que isso seja facilmente classificado como algo rotineiro, e todos os três induzem ao erro.

É necessário acesso local, então parece um problema de segunda instância, exceto que o acesso local é algo que os tenants, os executores de CI e as dependências não confiáveis já possuem. É necessário o Open vSwitch, então parece um problema de rede de nicho, exceto que o módulo é carregado automaticamente quando solicitado. E é necessário um namespace de usuário sem privilégios, então parece algo que as medidas de fortificação existentes já cobrem, exceto que a fortificação específica na qual a maioria das equipes do Debian e do Ubuntu confia nesse caso não funciona.

O histórico de versões traz outra lição. Uma alteração que removeu um limite de tamanho em março de 2025 transformou uma vulnerabilidade inativa há uma década em uma escalação de privilégios ativa, e ela chegou a ramificações de longo prazo como um backport comum, em vez de um lançamento. Uma fila de triagem baseada apenas nos números de versão do upstream teria considerado esses kernels fora do período de análise.

Para sistemas corrigidos de forma convencional, instale a atualização do fornecedor e confirme se o host inicializa com ela. Para frotas em que reinicializações de emergência geram riscos operacionais, o KernelCare bloqueia o caminho de validação vulnerável no kernel em execução sem tirar os sistemas do ar. De qualquer forma, a medida mais econômica atualmente é o bloqueio do módulo em todos os hosts que não utilizam o OVS: é reversível, de baixo impacto e remove o caminho de código em vez de tentar contorná-lo.

Adquira o KernelCare hoje mesmo →

Linha do tempo

Referências

• Asim Manizada, divulgação do OVSwrap, oss-security, 28 de julho de 2026, e o espelho do seclists
• Artigo técnico sobre o OVSwrap: https://heyitsas.im/posts/ovswrap
• Prova de conceito pública do OVSwrap e guarda BPF: https://github.com/manizada/OVSwrap
• Correção no código-fonte do Linux 3f1f75536668, “net: openvswitch: rejeitar atributos de ação aninhados com tamanho excessivo”
• Anúncio do Linux sobre o CVE-2026-64531
• Registro CVE, CVE-2026-64531
• Alertas aplicáveis ao RHEL, AlmaLinux, Rocky Linux, CloudLinux, Debian, Ubuntu e Amazon Linux