Ubuntu todavía no ha publicado un parche para el RCE 0day de Linux en casi 3 semanas

Artículo original ↗ Discusión en Hacker News ↗

Ubuntu está bajo presión por tardar casi tres semanas en publicar parches estables del kernel para una vulnerabilidad crítica de ejecución remota de código en Linux (CVE-2026-98432), mientras otras grandes distribuciones ya han liberado correcciones. Los comentaristas sopesan el proceso de Canonical, más lento pero más probado, frente al mayor riesgo y la mala imagen de un fallo explotable por red y ampliamente divulgado, compartiendo mitigaciones provisionales como reglas de iptables/nftables y preocupaciones sobre routers de consumo sin parchear. El episodio lleva a algunos administradores a reconsiderar Ubuntu en favor de Debian u otros sistemas y ha reavivado las críticas a la comunicación de Canonical, al tiempo que destaca el escepticismo sobre Freenode.net como fuente debido a su controvertida propiedad.

El parche retrasado de Ubuntu y el proceso

  • Muchos están frustrados porque los kernels LTS de Ubuntu siguieron sin parche durante semanas mientras otras distros (p. ej., RHEL, Debian, Gentoo, MikroTik, OpenWRT) publicaron correcciones.
  • Ubuntu tiene correcciones en el canal “proposed”, pero al parecer introducen regresiones para algunos sabores, lo que quizá explique la cautela.
  • Algunos sostienen que las muchas variantes del kernel de Ubuntu y la necesidad de pruebas amplias justifican una distribución más lenta; otros ven burocracia y a los “tipos de gobernanza” como obstáculos.
  • La falta de comunicación clara y proactiva por parte de Ubuntu es una queja recurrente.

Estrategias de mitigación y limitaciones

  • Varios comentarios comparten reglas de iptables/nftables para descartar paquetes TCP IPv4 con opciones IP (en raw PREROUTING), o para bloquear en general el tráfico de entrada/salida con opciones.
  • Deshabilitar MPTCP se discute como otra mitigación.
  • RHEL y otros afirman explícitamente que estas medidas solo “reducen la exposición” y no pueden impedir por completo la explotación.
  • Razones debatidas: procesos locales maliciosos, exploits encadenados (RCE a nivel de aplicación → RCE del kernel vía loopback), eBPF eludiendo netfilter, espacios de nombres de red separados (contenedores, Firejail).
  • Los cortafuegos por defecto de “denegar todo lo entrante” no corrigen esto por sí solos, ya que el error está en el manejo de conexiones TCP antes de las reglas de filtrado habituales.

Explotabilidad y riesgo en el mundo real

  • Algunos administradores con muchos servidores sin parchear informan no haber observado ataques y consideran que el riesgo está exagerado, citando la estrecha condición de carrera del fallo y el uso poco frecuente de opciones IP.
  • Otros responden que la ausencia de incidentes visibles no prueba seguridad, y mencionan gusanos anteriores que solo aparecieron tras cierto retraso.
  • Anécdotas de honeypots y conteo de paquetes sugieren que hay muy pocos paquetes con opciones IP en la práctica, pero los datos son anecdóticos e incompletos.

Impacto en la elección de distro y la confianza

  • Varios usuarios dicen que este incidente basta para trasladar futuros despliegues de Ubuntu a Debian u otras distros, viendo a voluntarios superando a un proveedor comercial.
  • Otros responden que muchos de los que se quejan no pagan a Ubuntu y que las expectativas quizá estén desalineadas.

Freenode.net como fuente

  • Varios comentarios advierten que freenode.net, tras la toma de control hostil, ya no es la red IRC de la comunidad y se la considera hostil al software libre.
  • A algunos les sorprende que HN lo enlace siquiera y recomiendan tratarlo como una fuente no confiable y sesgada.

Routers, IoT y plataformas alternativas

  • Preocupa que la mayoría de los routers/puntos de acceso de consumo ejecuten kernels Linux antiguos y sin parchear, con actualizaciones de firmware mínimas.
  • Las mitigaciones incluyen usar OpenWRT, Turris, MikroTik, actualizaciones gestionadas por el ISP o montar un router personalizado (por ejemplo, basado en Debian o BSD).
  • Algunos sostienen que los sistemas operativos de red especializados y los despliegues en HardenedBSD/FreeBSD muestran que Linux no siempre es el mejor kernel para objetivos de alto valor.