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 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:
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.
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:
net/ipv6: uso após liberação na fragmentação de IPv6 em ponte, por ponteiro obsoleto após realocação de buffer.lib/rhashtable: uso após liberação em percursos de tabela hash retomados depois de redimensionamento.net/ipv6: contagem de referências abaixo de zero no caminho de erro do roteamento IPsec.net/ipv4: uso após liberação na substituição de próximo salto, por percurso de lista de rotas IPv6 sem travamento.drivers/net: uso após liberação no driver de túnel GTP, com tabelas de busca liberadas durante criação de dispositivo malsucedida.security/keys: estouro de buffer em heap na atualização de chaves cifradas, por estouro de comprimento de 16 bits.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.
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.
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.
As ações abaixo valem para quem opera servidores, contêineres ou frotas de dispositivos baseados em Linux:
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.
Sistema experimental calcula idade fisiológica a partir de passos, sono e frequência de repouso, simula…
Dois modelos treinados antes do uso aprendem a rotear consultas e a prever a chave…
A Unit 42 detalhou um conjunto de ferramentas que opera dentro do navegador da vítima,…
O método GHARP, descrito por pesquisadores ligados à Apple e aceito no ACCV 2026, separa…
Pesquisadores publicaram em 27 de outubro de 2026 um benchmark que isola quem detém cada…
A Unit 42 publicou em 28 de outubro de 2026 um levantamento das ameaças que…