IA está achando milhares de vulnerabilidades antigas no kernel Linux

O número de vulnerabilidades conhecidas no kernel Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → disparou, e o motivo não é código pior: são ferramentas de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → varrendo trechos do kernel que ninguém revisava havia anos. Segundo reportagem do Tom's Hardware citada pela CNews, o total de falhas registradas saltou de cerca de 500 há poucos anos para perto de 2.000, e a curva continua subindo release a release.

Os números, versão por versão

A fonte compara diferentes builds do kernel para mostrar o ritmo. O que chama atenção é a aceleração nos últimos meses de 2026, quando o uso de analisadores de IA pela comunidade virou rotina.

Em quatro meses, entre a 7.0 e a 7.2, o número de falhas conhecidas cresceu 50%. A previsão dos especialistas ouvidos pelo Tom's Hardware é que a 7.3 ultrapasse a marca das 2.000.

Por que agora, e não antes

O ponto central da reportagem: esse crescimento não significa que o kernel ficou menos seguro ou que os desenvolvedores relaxaram. A causa é a combinação de dois fatores.

Primeiro, o tamanho e a idade da base de código. Em 2026 o kernel completou 35 anos e passou de 40 milhões de linhas, escritas por dezenas de programadores ao longo de décadas. Segundo, a capacidade das ferramentas de IA de varrer milhões de linhas em pouco tempo, incluindo trechos que ninguém tocava havia anos, exatamente onde as falhas costumam estar escondidas.

Ou seja: as vulnerabilidades sempre estiveram lá. A revisão humana simplesmente não voltava aos cantos empoeirados do kernel, e a IA volta.

Estamos completamente sobrecarregados.

Jakub Kicinski, mantenedor do kernel Linux

O ruído: nem tudo é falha crítica

Antes de qualquer pânico sobre a máquina que roda em produção, a fonte é explícita: boa parte das falhas encontradas é de baixa prioridade. Muitas aparecem em código de drivers pouco usados, e algumas são simplesmente alucinações da IA, ou seja, achados que não correspondem a vulnerabilidades reais.

Isso cria uma tarefa nova para a comunidade: separar o que é falha genuína e potencialmente perigosa do ruído gerado pelos scanners. No kernel Linux 7.3, que está sendo preparado, entre um terço e metade dos 648 patches propostos são correções de baixa prioridade, ajustes ou refinamentos originados por IA. Daí a frase de Kicinski sobre a sobrecarga: o volume de sugestões automáticas está engolindo o tempo dos mantenedores.

A discussão que isso reabriu: matar driver velho

O efeito colateral mais interessante para quem pensa arquitetura é político-técnico. Com a IA apontando falha atrás de falha em drivers antigos, a comunidade começou a questionar se vale a pena manter código legado que quase ninguém usa.

Em abril de 2026, o desenvolvedor Andrew Lunn propôs remover quase 28 mil linhas de código de rede legado, cobrindo hardware das eras ISA e PCMCIA, interfaces populares nos anos 1990 e início dos 2000 e hoje praticamente extintas. O raciocínio: historicamente esses drivers exigiam atenção mínima porque quase ninguém os usava, mas agora as falhas apontadas pela IA obrigam a corrigi-los de qualquer forma, gastando tempo dos mantenedores independentemente de haver ou não usuários reais.

O kernel 7.3 deve perder drivers antigos da SGI e da IBM, além de outros componentes obsoletos. É uma reavaliação de custo-benefício: a compatibilidade com hardware antigo compensa o esforço de manter aquela base de código viva e sem falhas?

O que muda para quem roda produção em Linux

O leitor que mantém serviços em Linux precisa ler esse crescimento de números com calma, e não como sinal de que a plataforma virou um queijo suíço. Alguns pontos práticos que se depreendem do cenário descrito pela fonte:

• Número maior de CVE não é sinônimo de mais risco. Um pico no total de falhas conhecidas reflete mais escrutínio, não degradação. Ler manchete de contagem de vulnerabilidades sem olhar severidade e superfície de ataque leva a decisão errada.
• Priorização vira o trabalho. Se metade dos patches de um release é ruído de baixa prioridade, quem gerencia patching interno vai sentir o mesmo problema em escala menor: mais avisos para triar. Vale acompanhar a severidade e o subsistema afetado, não a contagem bruta.
• Driver legado tende a sumir. Quem depende de hardware antigo ou de drivers de nicho deve ficar de olho nos changelogs. A remoção de código ISA/PCMCIA e de drivers SGI/IBM é um recado: manter kernel novo com periférico velho pode deixar de ser possível.
• A superfície que importa é a que você usa. Falha em driver que você não carrega não afeta sua máquina. Reduzir a superfície (kernel enxuto, módulos desnecessários fora) continua sendo a melhor defesa, e agora com respaldo estatístico do que a IA está encontrando.

Na prática, a leitura aqui é que a IA transformou o processo de auditoria do kernel, mas transferiu o gargalo para o julgamento humano: alguém ainda precisa decidir o que é real, o que é urgente e o que é código morto que deveria ir embora. Esse trabalho de triagem, e não a contagem de falhas, é o que vai definir a segurança prática do kernel nos próximos releases.

Fonte: CNews (Rússia)