Use-after-free no TCP do Linux: corrigir ou mitigar?

Seu kernel tem um use-after-free acessível remotamente no caminho de handshake TCP, sua distro ainda não publicou correção, e alguém já demonstrou um exploit de root funcional. Então, qual é o plano: esperar sentado ou começar a descartar pacotes no firewall? O use-after-free no TCP do Linux divulgado como CVE-2026-98432 é um estudo de caso limpo da decisão mais antiga em operações de segurança, corrigir versus mitigar, e a resposta honesta é que as duas opções não são nada simétricas. Uma delas de fato resolve o problema.

Já estive dos dois lados dessa decisão. Segurei um rollout emergencial de kernel porque a mitigação parecia boa o suficiente no papel, e também vi uma regra “temporária” de firewall apodrecer silenciosamente em produção por oito meses enquanto todo mundo esquecia a CVE que ela estava tapando. Esse bug é um bom gatilho para discutir quando cada abordagem vence, porque os trade-offs aqui são incomumente claros.

O que é, de fato, o use-after-free no TCP

A mecânica importa porque ela determina o que uma mitigação pode e não pode fazer. Quando seu servidor aceita uma conexão TCP sobre IPv4, o kernel acompanha o handshake meio aberto em um request socket leve e depois o promove a socket completo quando o handshake termina. Se o cabeçalho IPv4 do peer carregava opções, o kernel as salva para ecoá-las nas respostas. O bug: o kernel passava essas opções salvas para a nova conexão sem copiá-las, e então as liberava imediatamente, enquanto outra CPU ainda podia estar lendo-as para montar uma resposta de handshake. É um use-after-free, alcançável por um peer remoto e não autenticado, antes que uma única linha do código da sua aplicação sequer rode.

A correção upstream, de Eric Dumazet, tem quatro linhas: duas chamadas simples de kfree() viram kfree_rcu(), que adia a liberação até que todos os leitores tenham terminado de usar a memória. É a correção canônica do kernel para essa classe exata de bug, já que leitores sob RCU mantêm referências que você não enxerga, então você deixa o período de graça expirar antes de reaver a memória. A CNA do próprio kernel pontuou em CVSS 9.8. A Red Hat inicialmente deu 8.1, depois subiu para 9.8 Critical em 30 de outubro, citando a ausência de pré-requisitos de rede.

Dois detalhes mudam a conta da exposição. Primeiro, a condição de corrida falha de forma elegante: uma tentativa que dá errado apenas derruba o handshake sem causar pânico na máquina, então um atacante pode tentar indefinidamente. Segundo, o caminho de exploit que a Anthropic demonstrou mira hosts com um listener de multipath TCP. Segundo o Go Security Team, programas em Go abrem listeners MPTCP por padrão no Linux desde o Go 1.24, sempre que o kernel permitir. Verifique sua frota:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Uma saída vazia de ss -M significa que não há listener MPTCP. Mas não relaxe: o time do Go é explícito que o bug subjacente não é específico do MPTCP. É um UAF genérico no processamento de handshake, e o MPTCP é apenas o caminho que alguém provou de ponta a ponta.

O caminho do patch: kernel corrigido, reinício, pronto

Patch é meio entediante de descrever porque é a única opção que elimina a vulnerabilidade em vez de apenas remodelá-la. Kernels corrigidos foram publicados upstream em 11 e 15 de outubro para todas as linhas estáveis mantidas, e o bug remonta ao Linux 4.4. Isso significa que muitos sistemas de cauda longa são afetados, incluindo kernels antigos demais para o upstream sequer tocar.

A pegadinha é o reinício. Uma atualização de kernel não faz nada até a máquina inicializar nele, e o reinício é onde mora o custo operacional real: nós Kubernetes drenados, ensaios de failover, o primário do banco que ninguém quer derrubar em horário comercial. Por isso “é só aplicar o patch” é sempre correto e nunca suficiente como conselho. Você precisa de um plano de rollout: hosts canário primeiro, depois as camadas stateless, depois as stateful com janelas de manutenção. Se você já passou por uma rotação emergencial de kernel em toda a frota, já conhece o roteiro. As equipes que lidam bem com isso são as que ensaiaram a drenagem de nós quando nada estava pegando fogo. Os hábitos de engenharia defensiva que você constrói nas terças tranquilas são o que compensa durante uma CVE 9.8.

Uma armadilha que vale mencionar: dpkg -l ou rpm -q kernel mostrando um pacote corrigido não significa nada se o kernel em execução for anterior a ele. uname -r diz o que está de fato executando. Em sistemas da família RHEL, needs-restarting -r informa claramente se há um reinício pendente. Já revisei post-mortems em que a frota “corrigida” era uma frota de kernels instalados mas não em execução. Verifique a versão em execução contra o tracker da sua distro, não contra o número upstream, já que kernels de distro carregam backports sob o próprio versionamento.

A rota da mitigação: descartar opções IPv4, desabilitar MPTCP

A mitigação provisória publicada é uma regra do nftables que descarta pacotes TCP IPv4 de entrada que carregam opções de IP, a condição de disparo para o caminho vulnerável. Você pode complementar desabilitando o MPTCP (sysctl -w net.mptcp.enabled=0) se não o usa. Ambas são rápidas, não exigem reinício e podem ser implantadas com gerenciamento de configuração em uma tarde. Esse é o atrativo.

Agora a parte que deve moderar seu entusiasmo: o próprio boletim da Red Hat diz que sua regra “reduz a exposição a esta vulnerabilidade, mas não pode preveni-la totalmente”. Leia essa frase duas vezes. A mitigação estreita a superfície de ataque; não a fecha. Pacotes com opções de IP são raros em tráfego normal. A maioria dos middleboxes os descarta de qualquer forma, o que é um dos motivos pelos quais a exploração pela internet aberta é considerada improvável. Mas “raro” e “impossível” são palavras diferentes, e o bug está no código genérico de handshake, não apenas no caminho de opções que alguém por acaso testou.

Há também um custo mais sutil: mitigações criam uma falsa sensação de encerramento. O ticket vai para “quase pronto”, a urgência se esvai do esforço de patch, e seis semanas depois você ainda está rodando um kernel vulnerável atrás de um filtro de pacotes, com a memória institucional de por que isso era urgente se desvanecendo rapidamente. Já escrevi sobre esse padrão no contexto da janela de CVE crítica do PHP, onde as equipes que simplesmente tiraram o componente vulnerável do ar se saíram melhor do que as que empilharam filtros engenhosos. Mesma lição, outra stack.

Corrigir ou mitigar: quando cada opção vence

Aqui está minha avaliação honesta, depois de anos tomando essa decisão sob pressão.

• Há kernel corrigido para a sua distro. Patch vence de forma incontestável. Debian, SUSE Enterprise, Oracle UEK e Amazon Linux publicaram correções. Não existe mitigação mais inteligente que uma correção upstream de quatro linhas. Agende os reinícios, faça rollout em anéis e siga em frente.
• Ainda não há kernel corrigido, e a exposição é real. Mitigue imediatamente, pois é exatamente para isso que as mitigações servem. Ubuntu e RHEL ainda estavam “Vulnerable”/afetados no fim de outubro. Se você está exposto à internet com um listener MPTCP, descarte pacotes com opções de IP e desabilite o MPTCP hoje, enquanto acompanha o kernel corrigido como uma release que você está bloqueando.
• Exposto à internet, mas atrás de uma entrada gerenciada. Sua urgência cai. A orientação da AWS, de que o tráfego que passa pelos load balancers, CloudFront ou API Gateway deles não chega às suas instâncias como TCP bruto não confiável, é sólida. Mitigue mesmo assim, pois é barato, e aplique o patch em um ciclo normal, não em um ciclo emergencial.
• Sistemas single-core ou de fila única. Prioridade mais baixa. A condição de corrida precisa de processamento concorrente de pacotes em múltiplas CPUs. Sistemas embarcados e VMs minúsculas ganham algum fôlego, mas também tendem a ser as máquinas que ninguém jamais reinicia, então não deixe “baixa prioridade” virar “nunca”.
• Kernels fora de suporte (upstream anteriores a 5.10). A mitigação é sua única opção independente do upstream. Este é o cenário em que mitigações realmente vencem, porque a alternativa é um backport do fornecedor que pode nunca chegar. É também um sinal alto de que a própria máquina é a vulnerabilidade, e a correção real é substituí-la.

A lacuna das distros é a verdadeira história

O detalhe que deveria incomodar você não é o bug, já que correções de UAF de quatro linhas chegam aos kernels estáveis todo mês. É que duas das maiores distribuições de servidor do planeta, Ubuntu e RHEL, ainda não tinham correções publicadas mais de duas semanas depois do upstream. Enquanto isso, o Amazon Linux havia corrigido todos os seus kernels e o AlmaLinux, uma recompilação comunitária, já tinha kernels corrigidos em teste antes do próprio upstream. A comunidade do HN percebeu, e tem razão em se irritar: são as distribuições que mais se vendem como prontas para servidores.

Para quem está na prática, a conclusão é pouco glamourosa: sua janela de exposição é definida pelo pipeline de backport do seu fornecedor, não pelo upstream. Isso aponta para duas coisas. Primeiro, conheça as URLs de tracker da sua distro e de fato as acompanhe. Esta CVE ficou em “Received” no NVD sem análise enquanto a CNA do kernel, a Red Hat e as distros já tinham páginas detalhadas. Segundo, trate a agilidade da distro como critério de seleção. O Amazon Linux acabou de demonstrar um pipeline de correção de kernel bem mais rápido que os dois incumbentes. Isso não vai importar numa apresentação comercial, mas importa no fim de semana do Halloween quando uma 9.8 aparece.

O exploit escrito por IA muda o relógio

A linha mais consequente da divulgação é fácil de passar batido: a Anthropic relata que seu modelo Claude produziu um exploit funcional de root remoto, após um prompt inicial, levando menos de uma hora de tempo de máquina para ir do vazamento de ponteiro do kernel até um shell root. Eles não publicaram o exploit, e os céticos no HN se divertiram com o enquadramento de “confia em mim, mano”. Justo. Mas mesmo descontando o marketing, a direção é inequívoca: o tempo entre “o diff entra na árvore estável” e “existe um exploit funcional” está encolhendo, porque o gargalo de escrever exploits nunca foi o bug, e sim o humano capaz de ler o diff e fazer o heap grooming.

Isso comprime a janela de decisão entre corrigir e mitigar. Quando o desenvolvimento de exploit levava semanas, “mitigar agora, aplicar o patch na próxima janela de manutenção” era defensável. Quando um modelo consegue produzir um PoC durante a noite a partir de um commit público, sua fase de mitigação precisa ser medida em horas, e a fase de patch em dias. A correção de quatro linhas é pública. Qualquer um pode estudá-la. Presuma que o exploit também é.

Minha recomendação

Aplique o patch. Use a mitigação apenas como ponte, e coloque data de expiração nessa ponte. Na prática: se sua distro tem kernel corrigido, comece o rollout agora e verifique uname -r após cada reinício. Se você está no Ubuntu ou no RHEL, implante o descarte de opções IP e desabilite o MPTCP hoje, e trate a correção de kernel ausente como uma dependência bloqueante, verificando o tracker diariamente e não semanalmente. Priorize o que estiver exposto à internet com um listener MPTCP, depois tudo o mais que aceita TCP de entrada, que é quase tudo. Containers não salvam você; eles compartilham o kernel do host, então corrija os nós.

A lição mais profunda é a que este bug ensina a cada poucos anos sob um novo número de CVE: mitigações compram tempo, mas só patches fecham buracos, e o tempo que as mitigações compram está ficando cada vez menor. Construa a musculatura para rollouts de kernel rápidos e seguros antes de precisar dela, porque a próxima correção de quatro linhas já está na fila de alguém.