Linux sob enxurrada de bugs achados por IA: faltam revisores

Encontrar bugs no kernel do Linux ficou fácil. Corrigi-los, nem tanto. Segundo o ZDNET, que fez o balanço em 12 de novembro de 2026, as ferramentas de IA geram agora tantos relatórios de bugs e patches que quem precisa revisá-los está se esgotando, e pelo menos um mantenedor conhecido do kernel parou de revisar a maior parte do código.

Uma CVE (Common Vulnerabilities and Exposures) é o identificador público dado a uma falha de segurança documentada. Um mantenedor é uma pessoa, voluntária ou assalariada, responsável por uma parte do kernel e que decide quais patches entram. Um revisor (reviewer) lê um patch proposto e confere se ele está correto antes da integração. O kernel do Linux, o núcleo do sistema operacional que roda de smartphones a supercomputadores, depende de um número pequeno dessas pessoas.

Qual é o tamanho da enxurrada de relatórios de bugs do Linux?

Segundo o ZDNET, a equipe de CVEs do Linux relatou uma média de 27 CVEs por dia em 2026, até 2 de novembro. O ZDNET explica o volume em parte por uma regra própria do kernel: no Linux, qualquer bug pode ser potencialmente um bug de segurança.

Segundo o Tom's Hardware, que repercutiu uma reportagem do Phoronix de 28 de agosto, o kernel se aproxima de 2.000 CVEs corrigidas por versão, contra cerca de 500 durante boa parte da era Linux 6.x. Um slide de Greg Kroah-Hartman, mantenedor do kernel estável, preparado para a conferência Kernel Recipes 2026, mostrava números acima de 1.000 com o Linux 7.0 e acima de 1.500 com o Linux 7.2. Se a tendência continuar, o Linux 7.3 poderá passar de 2.000, de acordo com o Tom's Hardware.

O Tom's Hardware atribui o salto principalmente a pessoas que vasculham, com ferramentas de IA, um código-fonte que cresceu para mais de 40 milhões de linhas em 35 anos, e não a uma queda repentina na qualidade do kernel. Essas ferramentas chegam a cantos obscuros que humanos raramente revisitam e ocasionalmente encontram defeitos reais: os registros de CVE do Linux deste ano já creditam à análise estática assistida por IA descobertas depois confirmadas pela Intel Product Security.

A reportagem do ZDNET acrescenta um número do lado corporativo. O FORGE Lab da Microsoft disse que seu sistema de varredura por IA, o MDASH, produziu 59 relatórios de bugs do kernel Linux upstream, incluindo uma falha com pelo menos 21 anos. Segundo o laboratório, transformar essas descobertas em relatórios exigiu mais de quatro pessoas-mês, porque o esforço humano é o gargalo, e ele descreveu a busca e a correção de bugs como drasticamente desequilibradas. No lado do Windows, o ZDNET observa que o último Patch Tuesday trouxe 726 CVEs, a maioria vinda de descoberta por IA.

Por que os mantenedores do kernel estão esgotados?

A pressão aparece em casos com nome. Segundo o ZDNET, em 10 de novembro de 2026, Lorenzo Stoakes, engenheiro da ARM e mantenedor do kernel, parou de revisar código das seções de gerenciamento de memória, misc, reclaim e Rust, que cobria como revisor. Ele contribui com o kernel desde 2014. Escreveu que, com o ritmo atual de séries de patches geradas por IA, não tem mais disponibilidade para oferecer revisão geral, exceto nas áreas que ele mesmo mantém. Acrescentou que o «slop» gerado por IA aparecia de vez em quando, depois toda semana, depois a cada poucos dias, e hoje responde por cerca de metade do que ele vê, ou mais.

Greg Kroah-Hartman, mantenedor do kernel estável, disse o mesmo numa sessão de perguntas e respostas na Open Source Summit Europe, segundo o ZDNET: não há gente suficiente para revisar a avalanche de patches gerados por LLMs, e os mantenedores estão esgotados há dez anos. O pedido dele foi direto: o kernel precisa de mais revisores.

O Tom's Hardware traz um exemplo mensurável em redes. No pull request de rede do Linux 7.3, o mantenedor Jakub Kicinski estimou que entre um terço e metade dos 648 patches net-next tratados no ciclo pareciam correções de baixa prioridade, limpezas ou esclarecimentos impulsionados por IA. Ele escreveu que a equipe está completamente sobrecarregada.

A carga de trabalho muda o que o kernel mantém. Segundo o Tom's Hardware, o desenvolvedor Andrew Lunn propôs em abril remover quase 28.000 linhas de código de rede legado para hardware da época ISA e PCMCIA, porque a IA e as ferramentas de fuzzing passaram a encontrar defeitos que os mantenedores se sentiam obrigados a corrigir, mesmo que ninguém use esse hardware. O Linux 7.3 está removendo código antigo de drivers da SGI e da IBM, e o driver de sistema de arquivos FreeVxFS foi retirado depois que seu mantenedor disse que o velho código de compatibilidade servia sobretudo de alimento para verificadores automáticos de bugs.

A comunidade do kernel rejeita a IA?

Não, e o Tom's Hardware é explícito nesse ponto. O próprio Greg Kroah-Hartman usou ferramentas de fuzzing assistidas por IA, executadas localmente, para encontrar bugs do kernel. A queixa é contra a saída de IA não verificada entregue a humanos para validação. Segundo o Tom's Hardware, ele proibiu recentemente patches gerados por LLM no subsistema staging do kernel, exceto correções de segurança legítimas, e a orientação atualizada do kernel alerta que relatórios gerados por IA e enviados sem verificação humana podem desperdiçar o tempo dos mantenedores. A equipe também conseguiu acesso a vários modelos de fronteira para ajudar a revisar patches e filtrar resultados alucinados.

As correções estão começando a alcançar os relatórios?

Há sinais iniciais, mas nada conclusivo. Segundo o ZDNET, Linus Torvalds escreveu numa mensagem na Linux Kernel Mailing List que boa parte do código novo do Linux 7.4-rc2 foi impulsionada por correções feitas com IA. Disse que, pelo menos no lado do BPF, as correções agora chegam mais rápido que os novos relatórios, que a maioria das outras áreas não chegou a esse ponto e que isso pode indicar que a maré está virando. O conselho dele foi não prender a respiração.

Kroah-Hartman é menos otimista. Disse ao ZDNET que o projeto está chegando perto, mas ainda não chegou, e se recusou a estimar quando as correções de IA aprovadas por humanos vão superar os relatórios de bugs de IA. Daniel Stenberg, criador do projeto cURL e crítico ferrenho de relatórios de IA de baixa qualidade, disse ao ZDNET que acredita que seu projeto administra a enxurrada razoavelmente bem até agora, embora o volume suba e desça conforme quem envia novas descobertas em determinada semana.

• 27 CVEs por dia: a média da equipe de CVEs do Linux até 2 de novembro de 2026, segundo o ZDNET.
• Perto de 2.000 CVEs por versão do kernel, contra cerca de 500 em boa parte da era 6.x, segundo o Tom's Hardware.
• Entre um terço e metade de 648 patches de rede do ciclo do Linux 7.3 considerados trabalho de baixa prioridade impulsionado por IA, segundo o mantenedor Jakub Kicinski.

O que isso muda para uma empresa?

Para uma empresa brasileira que roda Linux em servidores, contêineres, equipamentos de rede ou dispositivos embarcados, a lição prática é que o número de avisos de segurança do kernel vai continuar subindo enquanto as pessoas por trás de cada correção continuam escassas. Uma contagem de CVEs diz pouco sobre o risco por si só, porque muitas entradas novas envolvem drivers obscuros; o que importa é quais delas afetam o hardware e a configuração do kernel que você realmente usa.

Daí saem três hábitos. Acompanhe as versões do kernel estável entregues pela sua distribuição e encurte o tempo para aplicá-las. Mantenha um inventário dos recursos e drivers do kernel que você ativa, para triar avisos rapidamente. E, se sua equipe abre relatórios de bugs com ajuda de IA, peça que uma pessoa reproduza cada problema antes, porque a própria orientação dos mantenedores diz que relatórios não verificados desperdiçam o tempo deles. As empresas que dependem do Linux também podem ajudar diretamente, financiando ou oferecendo tempo de revisão, o recurso mais escasso segundo Kroah-Hartman.

Uma ressalva: as fontes não dizem quando as correções vão superar os relatórios, e a observação de Torvalds sobre o BPF é descrita como animadora, mas limitada a essa área. Vale tratar o período atual como uma temporada pesada de correções, não como uma tendência consolidada.