Ubuntu ainda não lançou patch para RCE 0day no Linux há quase 3 semanas
A Ubuntu está sob fogo por demorar quase três semanas para lançar patches estáveis de kernel para uma vulnerabilidade crítica de execução remota de código no Linux (CVE-2026-98432), enquanto outras grandes distribuições já liberaram correções. Os comentaristas ponderam o trade-off entre o processo de lançamento mais lento e mais testado da Canonical e o risco elevado e a má imagem de um bug de rede explorável publicamente, compartilhando mitigações temporárias como regras de iptables/nftables e preocupações com roteadores de consumo sem patch. O episódio está levando alguns administradores a reconsiderar a Ubuntu em favor do Debian ou de outros sistemas e reacendeu críticas à comunicação da Canonical, além de destacar o ceticismo em relação ao Freenode.net como fonte devido à sua controvertida propriedade.
Patch atrasado da Ubuntu e processo
- Muitos estão frustrados porque os kernels LTS da Ubuntu permaneceram sem patch por semanas, enquanto outras distros (por exemplo, RHEL, Debian, Gentoo, MikroTik, OpenWRT) já tinham liberado correções.
- A Ubuntu tem correções no canal “proposed”, mas elas aparentemente introduzem regressões para alguns flavors, o que pode explicar a cautela.
- Alguns argumentam que as muitas variantes de kernel da Ubuntu e a necessidade de testes amplos justificam um rollout mais lento; outros veem burocracia e “tipos da governança” como bloqueios.
- A falta de comunicação clara e proativa por parte da Ubuntu é uma reclamação recorrente.
Estratégias de mitigação e limitações
- Vários comentários compartilham regras de iptables/nftables para descartar pacotes TCP IPv4 com opções IP (em
raw PREROUTING), ou para bloquear entrada/saída com opções de forma geral. - Desativar MPTCP é discutido como outra mitigação.
- RHEL e outros afirmam explicitamente que essas medidas apenas “reduzem a exposição” e não conseguem impedir totalmente a exploração.
- Razões discutidas: processos locais maliciosos, exploits em cadeia (RCE na camada de aplicação → RCE no kernel via loopback), eBPF contornando o netfilter, namespaces de rede separadas (containers, Firejail).
- Firewalls padrão de “negar tudo de entrada” não corrigem isso por si só, já que o bug está no tratamento da conexão TCP antes das regras de filtragem típicas.
Explorabilidade e risco no mundo real
- Alguns administradores com muitos servidores sem patch relatam não ter observado ataques e veem o risco como exagerado, citando a condição de corrida estreita do bug e o uso raro de opções IP.
- Outros rebatem que a ausência de incidentes visíveis não prova segurança, referenciando worms anteriores que só apareceram depois de algum atraso.
- Anedotas de honeypots e contagem de pacotes sugerem pouquíssimos pacotes com opções IP em ambiente real, mas os dados são anedóticos e incompletos.
Impacto na escolha de distro e na confiança
- Vários usuários dizem que este incidente é suficiente para mover futuras implantações da Ubuntu para Debian ou outras distros, vendo voluntários superando um fornecedor comercial.
- Outros respondem que muitos reclamantes não pagam pela Ubuntu e que as expectativas podem estar desalinhadas.
Freenode.net como fonte
- Vários comentários alertam que o freenode.net, após a tomada hostil, não é mais a rede IRC da comunidade e é visto como hostil ao open source.
- Alguns se surpreendem que o HN ainda linke para ele e recomendam tratá-lo como uma fonte não confiável e tendenciosa.
Roteadores, IoT e plataformas alternativas
- Há preocupação de que a maioria dos roteadores/APs de consumo rode kernels Linux antigos e sem patch, com atualizações mínimas de firmware.
- As mitigações incluem usar OpenWRT, Turris, MikroTik, atualizações gerenciadas pelo ISP ou operar um roteador personalizado (por exemplo, baseado em Debian ou BSD).
- Alguns argumentam que sistemas operacionais de rede especializados e implantações em HardenedBSD/FreeBSD mostram que Linux nem sempre é o melhor kernel para alvos de alto valor.