FreeBSD, execve() e o parêntese que virou root

O FreeBSD soltou o FreeBSD-SA-26:13.exec no dia 29 de abril de 2026 para a CVE-2026-7270, uma vulnerabilidade local no execve(2) que, segundo o advisory oficial, pode permitir que um usuário sem privilégio obtenha privilégio de superusuário.

Traduzindo sem colocar fumaça de palco: é bug no caminho do kernel que executa programas.

E quando o bug mora no caminho que o sistema usa para executar binário, script, argumento e variável de ambiente, o nível da conversa sobe rápido. Não é aquele “bugzinho no app”. É o encanamento da casa.

Uma linha errada em caminho de kernel é o tipo de economia que depois cobra imposto emocional.

O advisory é bem seco, como todo bom documento de segurança que não quer virar roteiro de série ruim: um bug de precedência de operador no kernel cria um cenário em que um buffer overflow permite que dados controlados pelo atacante sobrescrevam buffers adjacentes de argumentos do execve(2).

Ponto importante: o FreeBSD não está dizendo “tem exploração remota varrendo a internet”. O texto oficial fala em local privilege escalation e usa “may be exploitable”. Então não vou inventar campanha ativa, botnet ou apocalipse só para ganhar engajamento.

O que dá para afirmar com segurança é pior do que parece: todas as versões suportadas do FreeBSD foram marcadas como afetadas, não há workaround, e a recomendação oficial é atualizar e reiniciar.

Sim, reiniciar. Aquele momento em que o uptime de 900 dias deixa de ser medalha e vira prova material de negligência.

O que o execve(2) faz, sem palestra de manual

O execve(2) é a chamada de sistema usada para lançar uma nova imagem executável. Ele recebe o caminho do programa, argumentos e variáveis de ambiente.

Também entra na jogada quando você executa scripts com uma linha de interpretador, o famoso #!. O kernel precisa ajustar argumentos, encaixar o interpretador, reorganizar strings e preparar tudo para o novo processo nascer.

É uma operação comum, antiga e crítica.

E por ser comum, qualquer bug ali é uma praga com crachá de funcionário efetivo.

Não precisa o atacante “invadir o kernel” com raio laser. Se ele já tem acesso local sem privilégio, ele tenta empurrar o sistema para um estado onde a cópia de argumentos passa do limite correto e pisa em região vizinha de memória usada pelo próprio fluxo de execução.

Esse é o tipo de bug que não parece cinematográfico porque não tem tela verde, caveira 3D ou senha piscando. Só tem aritmética errada.

E aritmética errada no kernel é poesia para gente com más intenções.

A linha que matou o sossego

O commit de correção mostra uma mudança pequena em sys/kern/kern_exec.c:

- args->endp - args->begin_argv + consume
+ args->endp - (args->begin_argv + consume)

Essa é a parte didática e humilhante.

Sem os parênteses, a expressão calcula outro tamanho para o memmove(). Em vez de copiar só o trecho sobrevivente do buffer, o cálculo pode incluir bytes demais. O resultado, segundo o commit, é que o espaço de usuário conseguia fazer a cópia estourar para regiões KVA adjacentes do execve.

KVA aqui é Kernel Virtual Address. Não é um buffer qualquer do seu programinha. É memória virtual do kernel.

O próprio commit diz que isso habilita, entre outras coisas, injetar variáveis de ambiente em processos privilegiados. Eu não preciso decorar isso com terror barato. Essa frase já chega carregando a cadeira na mão.

Variável de ambiente parece inofensiva até ela entrar no lugar errado, no processo errado, com privilégio errado. Muita superfície histórica de abuso passa por ambiente, loader, runtime, caminho de biblioteca, locale, configuração e comportamento herdado.

Não estou dizendo que todo binário privilegiado do FreeBSD vira alvo automático. Isso seria chute. O que estou dizendo, com base no advisory e no commit, é que permitir dados controlados pelo usuário atravessarem para buffers adjacentes no caminho do execve() é uma falha de classe alta. Daquelas que não se trata com “vamos monitorar”.

Trata com patch e reboot.

“Mas é só local”

Essa frase deveria acionar sirene.

Vulnerabilidade local não significa vulnerabilidade pequena. Significa que o atacante precisa chegar antes como usuário não privilegiado. Em ambiente doméstico, isso pode parecer pouco. Em ambiente real, é terça-feira.

Pensa nos lugares onde usuários sem privilégio existem por desenho:

1. servidores multiusuário;
2. shells de cliente;
3. bastion hosts;
4. runners de CI/CD;
5. ambientes de build;
6. jails e workloads isolados;
7. appliances que expõem algum serviço e depois deixam o atacante virar usuário interno.

Não estou afirmando que essa CVE tem escape público de jail ou exploração remota. O advisory não diz isso.

A provocação é outra: se o seu modelo de risco trata “local” como “irrelevante”, você está assumindo que ninguém nunca vai conseguir uma conta baixa, um serviço comprometido, uma chave SSH esquecida, um job de CI abusável ou um usuário interno fazendo bobagem.

Ou seja, você está planejando segurança com a mesma confiança de quem compra extensão elétrica no camelô e liga rack nela.

O que se sabe com certeza

Aqui vai a parte sem espuma:

• O advisory oficial é FreeBSD-SA-26:13.exec.
• A CVE é CVE-2026-7270.
• O problema afeta todas as versões suportadas do FreeBSD, segundo o projeto.
• O módulo afetado é execve(2), no core do sistema.
• O impacto descrito é potencial escalação local de privilégio para superusuário.
• O NVD lista a falha como CWE-783: Operator Precedence Logic Error.
• A pontuação publicada pela CISA-ADP no NVD é CVSS 3.1 7.8 HIGH, com vetor local e privilégio baixo.
• Não existe workaround oficial.
• A correção saiu em branches stable/releng, incluindo 15.0-RELEASE-p7, 14.4-RELEASE-p3, 14.3-RELEASE-p12 e 13.5-RELEASE-p13.

Isso é o suficiente para qualquer time decente agir.

Se você administra FreeBSD exposto a usuário não confiável e está esperando “mais detalhes”, parabéns: você está terceirizando sua priorização para o atacante.

O que eu não vou afirmar

Não vou afirmar exploração em massa. Não encontrei isso no advisory oficial.

Não vou afirmar ataque remoto. A classificação é local.

Não vou afirmar que qualquer jail vira root no host. O material oficial não crava isso.

Não vou colocar payload, PoC ou receita de exploração aqui. O pesquisador creditado publicou uma análise técnica pós-divulgação, mas a utilidade deste post é defesa, não transformar leitor curioso em estagiário de incidente.

O que dá para provocar com honestidade é simples: se um bug local no caminho de execução do kernel “pode” virar root, a janela entre “pode” e “alguém automatizou” costuma ser menor do que a janela entre “vamos abrir chamado de mudança” e “o comitê aprovou o reboot”.

E essa diferença de tempo é onde mora o prejuízo.

O que fazer agora

Atualize.

Reinicie.

Depois confirme versão e patch level. O advisory oficial lista os ramos corrigidos e os métodos de atualização via pkg, freebsd-update ou patch de código-fonte. Se você roda FreeBSD em produção e não sabe por qual caminho ele foi instalado, esse é um problema operacional separado. Bonito inclusive. Dá para pendurar na parede do departamento como “governança por arqueologia”.

Prioridade alta para:

• servidores com contas de usuários;
• máquinas com acesso SSH amplo;
• hosts de build;
• ambientes que executam código de terceiros;
• sistemas FreeBSD usados como base de appliance;
• qualquer lugar onde um usuário não privilegiado conseguiria virar problema se ganhasse root.

O mais irritante desse caso é o tamanho da correção. Uma linha.

Mas é justamente isso que deixa a história boa: segurança de sistema operacional não falha só em desenho grandioso. Às vezes falha porque alguém esqueceu que matemática de ponteiro sem parêntese é uma forma bem cara de roleta.

Fontes e Referências

Fontes oficiais

• FreeBSD Security Advisory FreeBSD-SA-26:13.exec
• FreeBSD VuXML: CVE-2026-7270
• Patch oficial do FreeBSD: SA-26:13 exec.patch
• Assinatura PGP do patch oficial

Código e correção

• FreeBSD cgit: commit main 8e8ddb05d071
• FreeBSD cgit: commit releng/14.3 f04c40607b8f
• GitHub mirror oficial freebsd/freebsd-src: commit da correção
• GitHub mirror oficial freebsd/freebsd-src: sys/kern/kern_exec.c corrigido

Bases e análise secundária

• NVD: CVE-2026-7270
• Calif.io: write-up técnico do pesquisador creditado