59 bugs no kernel Linux viram 33 CVEs em três meses

O FORGE Lab, grupo de pesquisa de segurança da Microsoft, publicou em 11 de novembro de 2026 um balanço de três meses de caça a falhas no núcleo do Linux. O texto, assinado pelo laboratório e pelo pesquisador Cen Zhang, descreve um esforço conduzido por um pesquisador em tempo integral e um estagiário que resultou em 59 relatórios públicos enviados à comunidade, 33 identificadores CVE atribuídos e 38 correções já incorporadas à árvore principal do kernel.

Oito desses CVEs tiveram exploração de escalada local de privilégio confirmada pela equipe — ou seja, não ficaram no terreno da falha teórica. O trabalho cobriu apenas um subconjunto de subsistemas, entre eles rede, sistemas de arquivos e módulos de segurança, com a varredura concentrada entre o fim de maio e meados de junho de 2026.

O que torna o relatório interessante não é a contagem de bugs no kernel Linux, e sim o que ele mede: a distância entre encontrar uma falha e efetivamente corrigi-la. A varredura inicial levou cerca de duas semanas em dois servidores; transformar aquilo em 59 relatórios consumiu mais de quatro meses-pessoa de trabalho humano.

O funil: de 26.502 achados brutos a 59 relatórios

O sistema interno usado na varredura recebeu o codinome MDASH. A Microsoft descreve um processo em etapas, com redução agressiva de volume a cada passo:

• 26.502 achados brutos, produzidos em aproximadamente duas semanas de varredura em dois servidores.
• 11.769 candidatos, após filtragem por confiança e triagem automatizada rápida.
• 621 casos com prova de conceito, depois que agentes tentaram reproduzir cada candidato em ambiente virtualizado com QEMU.
• 59 relatórios públicos, cerca de 9,5% dos casos com evidência de reprodução, após revisão por especialistas humanos.

Os 621 casos reproduzidos não viraram 621 relatórios por razões que a própria equipe tabulou: 266 (42,8%) compartilhavam a mesma causa raiz de outro caso, 163 (26,2%) foram descartados na revisão, em boa parte por impacto de segurança limitado, e 133 (21,4%) já haviam sido relatados ou corrigidos pela comunidade.

A Microsoft também informa quais modelos de linguagem sustentaram cada etapa. Na varredura de código, o consumo de tokens ficou assim: Sonnet 4.6 com 71,1%, GPT-5.4 com 20,1% e GPT-5.5 com 7,1%. Na reprodução, GPT-5.5 respondeu por 77,3%, Opus 4.6 por 13,2% e GPT-5.5-cyber por 9,4%. É um dado raro em relatórios desse tipo e ajuda a dimensionar o custo real da abordagem.

Os oito CVEs com escalada de privilégio confirmada

Dos 33 CVEs atribuídos, 24 recebem classificação Alta ou superior, com CVSS v3.1 igual ou maior que 7,0. O relatório lista oito com escalada local para root confirmada:

• CVE-2026-64554 — net/ipv6: uso após liberação na fragmentação de IPv6 em ponte, por ponteiro obsoleto após realocação de buffer.
• CVE-2026-64563 — lib/rhashtable: uso após liberação em percursos de tabela hash retomados depois de redimensionamento.
• CVE-2026-64580 — net/ipv6: contagem de referências abaixo de zero no caminho de erro do roteamento IPsec.
• CVE-2026-74561 e CVE-2026-74562 — net/ipv4: uso após liberação na substituição de próximo salto, por percurso de lista de rotas IPv6 sem travamento.
• CVE-2026-89789 — drivers/net: uso após liberação no driver de túnel GTP, com tabelas de busca liberadas durante criação de dispositivo malsucedida.
• CVE-2026-98222 — security/keys: estouro de buffer em heap na atualização de chaves cifradas, por estouro de comprimento de 16 bits.
• CVE-2026-98364 — net/xfrm: uso após liberação no roteamento IPsec, com dispositivo usado sem referência.

A concentração em subsistemas de rede é evidente: seis dos oito estão em net/ ou em drivers de rede. Os 25 CVEs restantes são listados em arquivo separado, referenciado pelo post original.

Estudo de caso: o ponteiro esquecido do rhashtable

O CVE-2026-64563 recebeu análise detalhada e serve bem para explicar por que falhas assim sobrevivem anos. O rhashtable é a tabela hash redimensionável compartilhada por vários subsistemas do kernel. Um commit de 2018 deixou de limpar o ponteiro de iterador salvo quando um percurso era pausado. Em um dos caminhos de retomada, depois que um redimensionamento liberava a tabela antiga de baldes, o ponteiro obsoleto permanecia ali — e o passo seguinte do percurso lia memória já liberada.

A falha exigia a coincidência de três condições: um percurso pausado e retomado, um redimensionamento durante a pausa e a remoção justamente da entrada salva. Como a maioria dos chamadores conclui o percurso em uma única passagem, o defeito atravessou sete anos sem ser notado.

O que o transformou em problema de segurança foi o ponto de alcance. O despejo de diagnósticos de socket via netlink é acessível a usuário sem privilégio, e o espaço de usuário controla o intervalo entre as respostas — o que permite influenciar a memória liberada e converter o ponteiro obsoleto em uma escrita restrita de 64 bits. A Microsoft relata que isso viabilizou escalada local de privilégio no Linux e também no Android com SELinux em modo de aplicação. A correção enviada à comunidade é de uma linha: limpar o ponteiro antes de retornar.

Há divergência de pontuação entre as bases públicas, e vale registrar. A Red Hat classifica o CVE-2026-64563 como Importante, com CVSS v3.1 de 7,3 e vetor CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H, enquadrado em CWE-825 (dereferência de ponteiro expirado). O registro no cve.org atribui 7,8, com a diferença concentrada no impacto de integridade. O crédito pela descoberta independente vai para Yuan Tan, da NebuSec, e o desenvolvimento do exploit funcional é atribuído a Frank Wu, da mesma empresa.

Bugs antigos e o gargalo que não é técnico

A idade média das falhas relatadas é de 8,1 anos entre a introdução no código e o relato público. Seis tinham de 15 a 19 anos e três passavam de 20. A mais antiga, o CVE-2026-74544, um deslocamento fora dos limites no cls_u32, estava presente havia pelo menos 21 anos.

Do lado da correção, os números mostram onde o processo trava. O primeiro relatório público saiu em 27 de junho de 2026; até 1º de setembro, 55 dos 59 já estavam em listas públicas, e os quatro restantes foram encaminhados até meados de outubro. Metade das 38 correções foi aceita na primeira submissão; a outra metade exigiu de uma a quatro revisões. O tempo entre o primeiro patch público e o lançamento em versão principal teve mediana de 41 dias, chegando a 108 no pior caso.

A conclusão que a própria equipe tira é sóbria e merece ser lida sem filtro de marketing: descobrir ficou rápido, corrigir não. O esforço humano — validação, revisão por mantenedores, coordenação — é o fator limitante, e despejar volume em mantenedores já sobrecarregados pode reduzir, não aumentar, a segurança efetiva. O segundo recado é igualmente direto: mais capacidade de processamento encontra mais falhas, mas não torna o sistema seguro, porque a varredura cobriu uma fração pequena do kernel e a descoberta é apenas uma parte do trabalho.

O que fazer em ambientes Linux

As ações abaixo valem para quem opera servidores, contêineres ou frotas de dispositivos baseados em Linux:

• Aplicar as atualizações de kernel da sua distribuição e confirmar, no aviso oficial do fornecedor, se os CVEs listados acima já estão contemplados na versão instalada — a correção na árvore principal não significa disponibilidade imediata no seu pacote.
• Priorizar os oito CVEs com escalada local confirmada, especialmente em máquinas multiusuário, hosts de contêineres e qualquer sistema em que código não confiável execute sem privilégio.
• Revisar a necessidade de acesso a diagnósticos de socket por processos sem privilégio e reduzir capacidades e namespaces concedidos a cargas de trabalho que não precisam deles.
• Manter registro de auditoria de carregamento de módulos e de operações privilegiadas, e monitorar travamentos repetidos de kernel, que podem indicar tentativa de exploração malsucedida.
• Consultar as bases oficiais antes de decidir prioridade, lembrando que as pontuações divergem entre fornecedores, como no caso do CVE-2026-64563.

Conclusão

O relatório do FORGE Lab é menos um anúncio de descoberta e mais um retrato de capacidade desequilibrada. Duas semanas de varredura automatizada produziram material suficiente para ocupar meses de revisão humana e de trabalho de mantenedores voluntários, e a maior parte das falhas encontradas era antiga, estável e inofensiva na prática até alguém demonstrar o caminho de exploração.

O ponto a observar nos próximos meses é se o ecossistema do kernel consegue absorver esse fluxo sem degradar a qualidade da revisão, e se outras organizações passarão a publicar o custo de suas campanhas de varredura com o mesmo nível de detalhe. Sem esse dado, fica difícil separar progresso real de volume.

Fontes e referências

• Microsoft Security Blog — “Lessons from 59 Linux Kernel Bug Reports”, FORGE Lab e Cen Zhang, 11 de novembro de 2026 — microsoft.com
• FORGE Lab — versão do mesmo balanço no blog do laboratório, com a tabela de CVEs — forge-blog.github.io
• Red Hat Customer Portal — CVE-2026-64563, pontuação, vetor e classificação de severidade — access.redhat.com
• OpenCVE — registro do CVE-2026-64563 e referências cruzadas — app.opencve.io
• The Linux Kernel Archives — árvore principal e notas de lançamento — kernel.org