O núcleo Linux publica 432 CVE em dois dias: o que isso realmente diz sobre a segurança do kernel

A equipa de segurança do núcleo Linux publicou 432 CVE em 48 horas. Número bruto espetacular, mas é preciso colocá-lo no seu lugar: é a consequência direta da política CNA adotada em 2024.

Fatos

A equipe de segurança do núcleo Linux publicou 432 CVE em dois dias — um pico que alimenta manchetes alarmantes e discussões nas listas de discussão. O número em si é incontestável, mas sua interpretação exige contexto.

Desde fevereiro de 2024, o projeto Linux tornou-se CNA (Autoridade de Numeração de CVE) junto à MITRE. Isso significa que a equipe do kernel pode, por si mesma, atribuir identificadores CVE aos seus patches de segurança, sem passar por uma entidade terceirizada. Resultado direto: a frequência de publicação de CVE explodiu, não porque o núcleo de repente ficou menos seguro, mas porque cada patch que poderia ter impacto na segurança agora recebe um CVE, por padrão.

Quem é impactado (e como interpretar esse número)

É preciso distinguir três categorias nessa massa de CVE:

1. Verdadeiras vulnerabilidades exploráveis remotamente ou em LPE — aquelas que justificam um patch imediato. Elas continuam minoritárias no fluxo.
2. Vulnerabilidades teóricas em subsistemas exóticos — drivers raramente compilados, código de arquiteturas pouco implantadas (SH, PA-RISC, IA-64 antes de sua remoção). CVE válido em teoria, impacto operacional próximo de zero para 99% das instalações.
3. Patches preventivos — race conditions, use-after-free difíceis de serem exploradas, vazamentos de informações menores. Devem ser corrigidos, mas não são emergências.

A política CNA do kernel, defendida por Greg Kroah-Hartman, é explícita: todo patch que afeta a segurança é um CVE, e cabe aos usuários (distribuições, empresas) filtrar o que lhes diz respeito. É uma inversão de responsabilidade em relação à era em que "chamava-se CVE apenas o que já estava sendo explorado" — mais honesta intelectualmente, mas que produz esses picos de números.

O ângulo que cresce: relatórios de bugs assistidos por IA?

A manchete da cobertura do The Register sobre o assunto é explícita: o pico "alimenta especulações sobre relatórios de bugs assistidos por IA". A ideia circula nas listas do kernel há vários meses: a democratização de ferramentas que executam fuzzing inteligente e análise estática aprimorada por LLM produz relatórios de bugs em fluxo contínuo, e parte desses relatórios (os verdadeiros positivos) acaba em patches que, sob a política CNA, tornam-se CVEs.

Neste momento, nada foi confirmado oficialmente pela equipe do kernel. A transição para a CNA ampla é suficiente para explicar o número bruto, sem necessidade de invocar um fator IA. Mas a questão merece ser levantada: se amanhã uma parte significativa dos CVEs for produzida por ferramentas de IA, o ecossistema deve tratá-los de forma diferente (canal dedicado, revisão humana obrigatória antes do CVE, marcação explícita nas descrições)? O debate ainda não está resolvido.

O que fazer agora

Análise

O cerne do assunto é um velho debate da segurança open source: qual nível de granularidade deve ser usado na divulgação de vulnerabilidades?

O modelo antigo ("só se fala das vulnerabilidades reais exploradas") tinha a vantagem de ser legível, mas como defeito criava um "ruído artificialmente baixo" de CVEs — as empresas acreditavam que seu kernel estava "limpo", enquanto dezenas de bugs de segurança passavam despercebidos a cada mês.

O novo modelo (CNA ampla) torna a realidade visível, mas inutilizável em sua forma bruta para a maioria das equipes. A mediação passa a ser responsabilidade das distribuições e das ferramentas de gerenciamento de patches, não do usuário final.

Um número honesto para se orientar: o núcleo Linux corrige cerca de 1.800 a 2.500 bugs por mês nas versões estáveis. A fração que afeta a segurança é estruturalmente significativa — o kernel é um monstro de 30+ milhões de linhas de C, grande parte em código de drivers pouco auditado. Que a publicação de CVE reflita essa realidade é saudável; que isso dê a impressão de um incêndio, não é.

Para lembrar

• 432 CVE em 2 dias = consequência da política CNA do kernel, não de um colapso de segurança.
• Uma hipótese de "relatórios assistidos por IA" circula para explicar o pico — não confirmada até o momento.
• Siga os advisories da sua distribuição, não o fluxo bruto do kernel.