En las últimas semanas el mundo Linux se ha visto sacudido por una nueva vulnerabilidad que, para muchos administradores, ha sido la gota que colma el vaso en una racha de fallos críticos en el kernel. Hablamos de Fragnesia, un exploit de escalada local de privilegios que se suma a la familia de fallos conocidos como Copy Fail y Dirty Frag, y que permite a cualquier usuario sin privilegios conseguir root con un único comando en sistemas vulnerables.

Tras Copy Fail y Dirty Frag, Fragnesia llega en un contexto de auténtica “fatiga de parches”: actualizaciones urgentes, reinicios encadenados y mitigaciones de emergencia. Sin embargo, dejarlo pasar no es una opción. El fallo afecta a múltiples distribuciones Linux y versiones de kernel, y ya existe una prueba de concepto pública totalmente funcional. En este artículo vamos a desgranar qué es Fragnesia, cómo funciona el ataque, qué distribuciones están afectadas, qué parches y mitigaciones existen y cómo comprobar si tu sistema está protegido.

Qué es Fragnesia y por qué se relaciona con Dirty Frag y Copy Fail

Fragnesia es un nuevo exploit de escalada local de privilegios (LPE) en el kernel de Linux que se encuadra en la misma familia de vulnerabilidades que Copy Fail (CVE-2026-31431) y Dirty Frag (también conocido como Copy Fail 2, CVE-2026-43284). Comparte con ellas la idea base: abusar de fallos lógicos en la pila de red y el manejo de memoria del kernel para obtener una primitiva de escritura en memoria que permita modificar archivos teóricamente de solo lectura y acabar ejecutando código como root.

El fallo ha sido bautizado como Fragnesia y rastreado como CVE-2026-46300, con una puntuación CVSS de 7,8. La vulnerabilidad fue descubierta por William Bowling, del equipo de seguridad V12. Poco después, Sam James anunció el problema en la lista de correo de OSS Security, aclarando que no se trataba de un simple reanálisis de Dirty Frag, sino de un bug distinto en la misma superficie funcional del kernel.

En términos prácticos, Fragnesia es el tercer fallo crítico de este tipo en apenas dos semanas: Copy Fail, Dirty Frag y ahora Fragnesia. Los tres se aprovechan de problemas en el manejo de datos en el kernel para corromper la caché de páginas (page cache) de archivos críticos como /usr/bin/su, pero Fragnesia lo logra a través de otra ruta: el subsistema ESP-in-TCP de XFRM.

Detalles técnicos: el subsistema XFRM ESP-in-TCP y el fallo de lógica

El núcleo de Fragnesia reside en un fallo de lógica en el subsistema Linux XFRM ESP-in-TCP, concretamente en la ruta del ULP (Upper Layer Protocol) denominada espintcp. XFRM es el marco del kernel encargado, entre otras cosas, de procesar tráfico IPsec, y ESP (Encapsulating Security Payload) es el protocolo que proporciona confidencialidad y autenticidad mediante cifrado (por ejemplo, AES-GCM), como ocurrió con una vulnerabilidad en el protocolo de red CAN BCM.

El ataque se basa en una situación muy concreta del kernel: cuando un socket TCP pasa a modo ESP-in-TCP después de que se hayan introducido en su cola de recepción páginas de fichero mediante llamadas como splice(2) o sendfile(2). En lugar de tratar esos datos como simples páginas provenientes de un archivo, el kernel los interpreta como si fueran texto cifrado ESP y aplica la “desencriptación” sobre ellas, modificando así las páginas de la caché de forma in situ.

Como consecuencia de este error, el kernel inyecta el flujo de claves de AES-GCM sobre páginas de la caché correspondientes a archivos de solo lectura, lo que se traduce en escrituras de bytes arbitrarias en la page cache. Controlando el IV (nonce) y otros parámetros, un usuario sin privilegios puede dirigir estas escrituras con mucha precisión. El resultado es una primitiva de escritura determinista que permite alterar una cantidad controlada de bytes de cualquier archivo legible, pese a que el sistema de ficheros lo marque como inmutable o de solo lectura.

La prueba de concepto pública se centra en modificar el binario /usr/bin/su en la caché de páginas. Inyecta un stub ELF de 192 bytes (posicionalmente independiente) en la copia en memoria de ese binario. A partir de ese momento, la siguiente vez que se ejecute su, se ejecutará el stub con privilegios de root, proporcionando una escalada instantánea sin necesidad de carreras de condiciones ni de otros trucos adicionales.

Mitigaciones temporales: cómo protegerte si no puedes reiniciar

Aunque lo recomendable es instalar un kernel parcheado y reiniciar lo antes posible, se han descrito mitigaciones temporales efectivas para quienes no puedan permitirse un reinicio inmediato. La buena noticia es que, dado que Fragnesia explota los mismos módulos base (esp4, esp6 y opcionalmente rxrpc) que Dirty Frag, la mitigación propuesta para este último sirve igualmente para Fragnesia.

La técnica consiste en bloquear la carga de los módulos vulnerables mediante la configuración de modprobe y, si estuvieran ya cargados, descargarlos de memoria. Se hace escribiendo una regla en /etc/modprobe.d/ que sustituye la carga de esos módulos por comandos inofensivos (como /bin/false). Después se invoca a rmmod sobre ellos, ignorando silenciosamente los errores si no están presentes.

En distribuciones como CloudLinux, el comando propuesto para Dirty Frag (que vale igual para Fragnesia) genera un archivo dirtyfrag.conf con reglas para esp4, esp6 y rxrpc, y a la vez intenta descargar los módulos activos. Si ya aplicaste esta mitigación por Dirty Frag, no tienes que hacer nada más para Fragnesia hasta que instales el kernel corregido, porque la superficie de ataque queda igualmente neutralizada.

Es importante tener en cuenta la compatibilidad: esp4 y esp6 son los transform del kernel para IPsec. Deshabilitarlos rompe los túneles IPsec que dependan de la ruta de datos del kernel (por ejemplo, strongSwan o Libreswan). La recomendación es no usar esta mitigación en hosts que terminen o enruten tráfico IPsec crítico. El módulo rxrpc es el transporte AF_RXRPC, usado casi exclusivamente por clientes AFS, y rara vez está presente en servidores web u otros escenarios generalistas.

Restaurar la caché de páginas tras aplicar la mitigación

Otro punto a menudo pasado por alto es que el exploit, al funcionar, puede dejar en memoria copias modificadas de binarios legítimos en la page cache. El ejemplo más típico es /usr/bin/su, pero podrían verse afectados otros binarios privilegiados si el atacante decide cambiar de objetivo.

Por ello, algunos avisos recomiendan que, tras aplicar la mitigación de blacklist de módulos, se proceda a vaciar la caché de páginas del sistema para forzar una recarga limpia desde disco. Esto se puede lograr escribiendo en /proc/sys/vm/drop_caches un valor que indique al kernel que libere cache page y dentries/inodes. Esta operación solo elimina páginas limpias, por lo que es segura en sistemas en producción, aunque puede generar un aumento puntual de E/S al disco cuando los binarios y datos se vuelvan a leer.

La idea es sencilla: si una instancia de Fragnesia ya hubiera sido ejecutada antes de mitigar, las páginas corrompidas se descartan y se volverá a usar la versión en disco sin alterar. Combinado con la blacklist de módulos, este paso reduce el riesgo de que una posible modificación residual en la cache siga siendo explotable o provoque comportamientos erráticos en el sistema.

Estado de los parches y recomendaciones de los proveedores

La mayoría de los grandes actores del ecosistema Linux han respondido de forma rápida al descubrimiento de Fragnesia. Distribuciones como AlmaLinux y CloudLinux han publicado o están finalizando kernels parcheados, mientras que Red Hat ha indicado que está evaluando hasta qué punto las mitigaciones existentes para vulnerabilidades previas cubren también CVE-2026-46300.

Varios proveedores de seguridad, como empresas asociadas a Google y Microsoft, han publicado análisis explicando que la vulnerabilidad permite a atacantes locales sin privilegios modificar contenidos de archivos de solo lectura en la caché de páginas y escalar a root mediante corrupción determinista de memoria. Wiz, por ejemplo, destaca que AppArmor y las restricciones sobre user namespaces sin privilegios pueden mitigar parcialmente el impacto al requerir técnicas adicionales para explotar con éxito el bug en algunos entornos.

Microsoft, por su parte, señala que no se ha observado explotación activa en la naturaleza en el momento de su comunicado, pero aun así insta a aplicar el parche tan pronto como esté disponible, utilizando las herramientas de actualización habituales. Cuando no sea posible parchear de inmediato, recomiendan aplicar las mismas mitigaciones propuestas para Dirty Frag: desactivar esp4, esp6 y funcionalidad relacionada con IPsec/XFRM no imprescindible, endurecer el acceso local interactivo y reforzar el monitoreo de actividades inusuales de escalada de privilegios.

Contexto de amenazas: mercado de exploits y fatiga de parches

El descubrimiento de Fragnesia se produce en un contexto en el que la explotación de fallos de escalada local en Linux gana valor en el mercado negro. Informes recientes describen a un actor, bajo el alias “berz0k”, ofreciendo un zero-day de escalada local en Linux por 170.000 dólares, supuestamente funcional en múltiples distribuciones. Según ThreatMon, el vendedor afirma que la vulnerabilidad es de tipo TOCTOU (Time-of-Check Time-of-Use), permite una escalada estable sin provocar cuelgues y utiliza un payload en forma de biblioteca compartida (.so) desplegada en /tmp.

Todo esto alimenta la sensación de saturación y cansancio que muchos administradores expresan: “otra vulnerabilidad de la misma categoría que Dirty Frag”, “ocho más como esta y ya desconecto”, comentan algunos de forma medio en broma, medio en serio. La realidad es que la sucesión de Copy Fail, Dirty Frag y Fragnesia está obligando a los equipos de sistemas a replantearse su estrategia de actualización del kernel, especialmente en entornos donde los reinicios frecuentes son muy costosos.

En este paisaje, soluciones de livepatching como KernelCare o mecanismos similares cobran protagonismo como alternativa para aplicar correcciones críticas sin interrumpir servicios, mientras que las distribuciones se ven presionadas para acortar al máximo los tiempos entre el descubrimiento, la publicación del fix upstream y la disponibilidad del paquete parcheado en repositorios estables.

En última instancia, Fragnesia se ha convertido en un caso de estudio de cómo una pequeña pieza de lógica en un subsistema especializado como XFRM ESP-in-TCP puede tener consecuencias devastadoras cuando se combina con mecanismos de caché de páginas y binarios privilegiados. Mantenerse al tanto de avisos de seguridad, listas de correo, blogs de distribuciones y canales de comunicación como Mattermost o X (antes Twitter) es clave para reaccionar con rapidez y minimizar la ventana de exposición.

La amenaza que representa Fragnesia no radica solo en su capacidad de dar root con un comando, sino en que demuestra hasta qué punto los entornos Linux modernos dependen de una cadena de confianza compleja que va desde el código del kernel hasta las herramientas de actualización y las políticas de endurecimiento. Estar protegido pasa por combinar parches oficiales, mitigaciones bien entendidas, soluciones de livepatch donde tenga sentido y una política clara de control de acceso local y monitorización, de forma que un fallo de este tipo no se convierta en el punto único de fallo para toda la infraestructura.

from Linux Adictos https://ift.tt/bkU2aul
via IFTTT

OpenZFS 2.4.2 ya está disponible como rama estable y se presenta como una actualización más de infraestructura que de grandes titulares, pero con un impacto importante para quienes gestionan sistemas de almacenamiento serios. Aunque sobre el papel pueda parecer un lanzamiento discreto, las novedades en compatibilidad de kernel y en estabilidad interna lo convierten en un paso relevante para administradores de sistemas que trabajen con Linux o FreeBSD.

Este lanzamiento se centra en cerrar brechas de compatibilidad y pulir errores que se manifestaban en escenarios complejos: cambios de kernel, reconstrucciones de pools, uso de dRAID o sustitución de discos. No hay funciones espectaculares pensadas para titulares comerciales, pero sí muchas correcciones que reducen riesgos de corrupción de datos y mejoran la convivencia entre OpenZFS y las versiones más recientes del kernel de Linux.

Compatibilidad de OpenZFS 2.4.2 con kernels Linux y FreeBSD

El punto más visible de OpenZFS 2.4.2 es la compatibilidad oficial con el kernel Linux 7.0, algo especialmente relevante para quienes ya están probando o desplegando distribuciones que integran esta rama. Hasta ahora, la versión estable anterior solo llegaba formalmente hasta Linux 6.19, lo que generaba fricciones en instalaciones que se movían más rápido a nivel de kernel que de stack de almacenamiento.

Con esta actualización, el proyecto mantiene un amplio rango de soporte, que abarca desde Linux 4.18 hasta 7.0. Esta horquilla resulta muy útil en entornos mixtos europeos donde coexisten servidores con distribuciones antiguas de soporte prolongado, máquinas de pruebas con kernels recientes y sistemas de producción más conservadores. Disponer de una única rama de OpenZFS que cubra todo ese abanico reduce excepciones, despliegues especiales y dolores de cabeza en la planificación de actualizaciones.

En la parte de FreeBSD, OpenZFS 2.4.2 sigue funcionando correctamente con FreeBSD 13.3 y versiones posteriores, incluido el salto a las ramas más nuevas como la serie 14.x. Esto mantiene alineado el ecosistema BSD con la evolución del sistema de archivos, algo relevante para centros de datos europeos que combinan infraestructuras Linux y FreeBSD en servicios de almacenamiento, copias de seguridad o plataformas de virtualización.

Cierre de la brecha con Linux 7.0

El soporte formal de Linux 7.0 no es solo un detalle de documentación: ataja un problema real que ya se estaba viviendo en distribuciones de nueva generación. Había casos, como instalaciones basadas en Ubuntu en versiones de desarrollo con kernel 7.0.0-15 y OpenZFS 2.4.1, donde los registros del sistema advertían de un uso experimental y posible riesgo de pérdida de datos al combinar ese kernel con la versión previa del módulo.

En un escritorio doméstico esos avisos pueden parecer anecdóticos, pero en un servidor de almacenamiento en producción no son algo que se pueda ignorar solo porque todo parezca funcionar a simple vista. Con 2.4.2, OpenZFS declara explícitamente compatible el kernel 7.0, lo que aporta un marco más claro para administradores que deben cuadrar políticas de actualización de kernel y estabilidad de pools ZFS en centros de datos o nubes privadas.

Además, el proyecto ha introducido ajustes iniciales orientados a Linux 7.1, anticipando cambios internos del kernel que pueden afectar a módulos externos como OpenZFS. No se trata aún de un soporte cerrado para 7.1, pero sí de un trabajo preparatorio que reduce la probabilidad de sorpresas incómodas cuando estas versiones empiecen a llegar a distribuciones de referencia en Europa.

Correcciones en rutas de datos y fiabilidad

Más allá del soporte de kernel, buena parte de las novedades de OpenZFS 2.4.2 se centra en rutas de datos críticas donde un fallo puede traducirse en corrupción o comportamientos inesperados. Aunque estos problemas suelen aparecer en escenarios poco frecuentes, son precisamente los que marcan la diferencia entre un sistema de ficheros robusto y uno que genera dudas a largo plazo.

Entre las correcciones destacadas se encuentran arreglos para errores de checksum en casos muy raros tras procesos de reconstrucción, una cuestión especialmente sensible cuando se trabaja con grandes pools o con discos que se han degradado. También se han solucionado problemas en configuraciones dRAID después de reconstrucciones con unidades deterioradas, lo que mejora la confianza en despliegues que usan esta tecnología para grandes volúmenes de datos.

La versión incorpora además correcciones en los procesos de importación de pools después de sustituciones de discos, un posible race condition asociado a los árboles de rangos (range trees) y un fallo de uso después de liberación (UAF) en la función dmu_write_direct_done. A ello se suma la solución de un problema de corrupción de lectura tras operaciones de clonación de bloques y truncado, un tipo de bug especialmente delicado porque puede pasar desapercibido hasta que los datos se necesitan de verdad.

Todo este conjunto de parches no se traduce en nuevas funciones llamativas, pero sí en un comportamiento más previsible durante operaciones de mantenimiento habituales: reconstrucción de vdevs, gestión de discos sustituidos, uso intensivo de snapshots y clones, dRAID y pruebas de rendimiento. Para organizaciones europeas que usan OpenZFS en almacenamiento crítico, estos son los detalles que ayudan a dormir un poco más tranquilos antes de un fin de semana.

Ajustes en initramfs, montaje y sistema

OpenZFS 2.4.2 también introduce mejoras en componentes de arranque y montaje que, aunque menos visibles, resultan importantes para que el sistema se comporte de forma consistente en distintas distribuciones. Entre ellas se incluyen correcciones en los scripts de initramfs, que intervienen en las fases iniciales de arranque cuando el sistema necesita acceder a pools ZFS muy pronto.

La nueva versión incorpora soporte para POSIX_FADV_DONTNEED, una sugerencia al sistema de ficheros y al kernel sobre el tratamiento de datos en caché, lo que ayuda a optimizar determinados patrones de acceso en servidores. Además, se han realizado ajustes en las rutas de montaje específicas para Linux y en la lógica de análisis de los nuevos parámetros de montaje, reduciendo casos límite en los que la configuración podía comportarse de forma diferente a lo esperado.

En paralelo, el proyecto ha aprovechado esta versión para actualizar la infraestructura de integración continua (CI), reforzar el uso de identificadores de licencia SPDX y aplicar cambios específicos del código para Linux que alinean mejor el módulo con las evoluciones del kernel. Estas mejoras internas no se perciben directamente en el día a día, pero son la base para que futuras versiones puedan desarrollarse y probarse de forma más fiable.

Recomendaciones de actualización para entornos europeos

Aunque el contenido de OpenZFS 2.4.2 invita a considerarlo una actualización recomendable, no es prudente tratarla como un simple parche trivial. El propio enfoque del proyecto y la naturaleza del sistema de ficheros aconsejan un proceso de despliegue controlado, especialmente en organizaciones con pools grandes o servicios críticos.

Para entornos empresariales y administraciones públicas en España y otros países de la UE, la práctica razonable pasa por revisar primero el estado de los paquetes proporcionados por la distribución, comprobar la configuración de DKMS o módulos, validar las características activas de los pools (pool features) y preparar un entorno de pruebas que reproduzca el escenario de producción lo mejor posible.

Un paso sensato consiste en introducir OpenZFS 2.4.2 inicialmente en sistemas de staging o laboratorios, aplicando allí los mismos patrones de uso que en producción: importación y exportación de pools, simulación de fallos de discos, uso intensivo de snapshots, clones, dRAID y pruebas de rendimiento. Una vez verificado el comportamiento, la actualización en producción debería planificarse en ventanas de mantenimiento con copia de seguridad reciente y estrategias claras de reversión.

En definitiva, OpenZFS 2.4.2 se presenta como una versión sobria pero muy relevante para la estabilidad de sistemas Linux y FreeBSD, especialmente allí donde conviven kernels antiguos y muy recientes. El soporte oficial para Linux 7.0, las numerosas correcciones en rutas de datos, los ajustes en initramfs y montaje, y la disponibilidad paralela de 2.3.7 conforman un paquete pensado para reducir riesgos más que para lucirse en presentaciones. Para quienes gestionan datos con cierta responsabilidad, este tipo de lanzamientos, discretos pero sólidos, son los que marcan la diferencia entre un susto mayúsculo y una operación de mantenimiento rutinaria.

from Linux Adictos https://ift.tt/zjJUGtZ
via IFTTT

Fwupd 2.1.3 llega en un momento clave para el ecosistema de firmware en Linux, justo después de que Dell y Lenovo se consolidaran como patrocinadores destacados del Linux Vendor Firmware Service (LVFS). Este contexto refleja un interés creciente de los grandes fabricantes por facilitar procesos de actualización más seguros y centralizados en sistemas basados en GNU/Linux.

Con esta publicación, el desarrollador principal de LVFS y Fwupd, Richard Hughes desde Red Hat, refuerza el papel de la herramienta como estándar de facto para gestionar actualizaciones de firmware. La edición 2.1.3 introduce nuevas funciones, amplía el soporte de hardware y corrige diversos errores que afectaban a determinados dispositivos, lo que se traduce en una experiencia algo más pulida para usuarios y administradores.

Principales novedades de Fwupd 2.1.3

Uno de los cambios más relevantes de Fwupd 2.1.3 es la incorporación de autenticación Redfish mediante bearer token. Esta mejora resulta especialmente útil en entornos de servidores y centros de datos donde Redfish se utiliza como estándar para la gestión remota de hardware, ya que facilita una integración más segura y flexible en infraestructuras empresariales.

La actualización también añade compatibilidad con varios chips XMC SPI, un tipo de memoria ampliamente utilizado en placas y dispositivos donde se almacena el firmware. Al ampliar el número de chips soportados, Fwupd puede llegar a más equipos y escenarios de uso, reduciendo la dependencia de herramientas específicas del fabricante.

Otro punto técnico destacado es la capacidad de analizar archivos JCat directamente dentro de la biblioteca de Fwupd, sin necesidad de recurrir a la librería externa libjcat. Este cambio ayuda a simplificar la pila de dependencias, lo que puede facilitar tanto el empaquetado para distribuciones GNU/Linux como el mantenimiento a largo plazo del proyecto.

Además de las nuevas funciones, la versión 2.1.3 incluye un conjunto de correcciones de errores que afectan a distintos componentes de hardware y a problemas menores detectados en versiones anteriores. Aunque no se detalla la lista completa en la información publicada, el enfoque apunta a mejorar la estabilidad general de la herramienta y reducir fallos durante el proceso de actualización de firmware.

Soporte para nuevos dispositivos SHIFTphone

Una de las incorporaciones más llamativas de Fwupd 2.1.3 es el soporte para las actualizaciones de firmware de los dispositivos SHIFT6MQ y SHIFTphone 8. Estos teléfonos modulares, fabricados por la empresa alemana SHIFT, se caracterizan por su reparabilidad y por un enfoque más sostenible en comparación con buena parte del mercado de smartphones.

La compatibilidad con Fwupd supone que los usuarios de SHIFT6MQ y SHIFTphone 8 podrán gestionar actualizaciones de firmware de forma más estándar dentro de entornos Linux, algo especialmente interesante para perfiles técnicos y comunidades que valoran la transparencia y el control sobre el software de sus dispositivos.

En el caso del SHIFTphone 8, se trata del modelo más reciente de la firma y el sucesor del SHIFT6MQ, que vio la luz en 2020. El nuevo terminal se encuentra en fase de reserva con un precio en torno a los 695 euros, reforzando la apuesta de SHIFT por un segmento de gama media-alta centrado en la durabilidad y la posibilidad de reparación.

Contexto: LVFS y el papel de los fabricantes

La llegada de Fwupd 2.1.3 se produce poco después de que Dell y Lenovo hayan reforzado su implicación con el Linux Vendor Firmware Service como patrocinadores de referencia. Este movimiento indica una apuesta más clara por ofrecer canales oficiales y centralizados para distribuir firmware, algo crucial en empresas y administraciones públicas que despliegan Linux a gran escala.

LVFS actúa como plataforma central para la distribución de firmware firmado y verificado en sistemas Linux, y Fwupd es la herramienta que se ejecuta en el lado del usuario o administrador para aplicar esas actualizaciones. A medida que más fabricantes de hardware se integran en este ecosistema, se reduce la necesidad de recurrir a utilidades específicas de cada marca o a sistemas operativos alternativos sólo para actualizar firmware.

En este escenario, la compatibilidad de nuevos dispositivos como los teléfonos de SHIFT ayuda a extender el modelo también al ámbito de la electrónica de consumo, no sólo a portátiles y servidores. Para la comunidad interesada en tecnología reparable y políticas de «derecho a reparar», este tipo de integraciones supone un paso más hacia dispositivos más abiertos y controlables por el usuario final.

La versión Fwupd 2.1.3 consolida la herramienta como pieza clave en la gestión de firmware en Linux, al combinar nuevas funciones técnicas como la autenticación Redfish por bearer token, un soporte de hardware más amplio que incluye chips XMC SPI y smartphones modulares como el SHIFTphone 8, y una serie de correcciones que buscan mejorar la estabilidad general. Junto con el impulso de fabricantes como Dell, Lenovo y compañías como SHIFT a través de LVFS, el ecosistema de actualización de firmware en Linux sigue avanzando hacia un entorno más homogéneo, transparente y manejable tanto para usuarios particulares como para organizaciones.

from Linux Adictos https://ift.tt/GrRkvnH
via IFTTT

Durante el Red Hat Summit de 2026 se ha presentado una de las apuestas más rompedoras dentro del ecosistema Fedora: Fedora Hummingbird, una distribución Linux rolling, basada en imágenes, pensada para agentes de IA y desarrolladores que viven en contenedores. No es “otra Fedora más”, sino un experimento muy serio para llevar el modelo distroless y las buenas prácticas de seguridad de los contenedores hasta el propio sistema operativo anfitrión.

Este nuevo sistema parte de un objetivo ambicioso: minimizar al máximo las vulnerabilidades (CVE) tanto en las imágenes de contenedores como en el sistema operativo, a la vez que ofrece una velocidad de actualización propia de Fedora Rawhide, pero empaquetada en forma de imágenes OCI, con actualizaciones atómicas, rollback integrado y un enfoque muy claro al mundo de la automatización y los agentes de IA.

Qué es Fedora Hummingbird y qué la hace diferente

Fedora Hummingbird es, en esencia, una distribución Linux de tipo rolling-release basada en imágenes. A diferencia de las Fedora tradicionales basadas en RPM instalados de forma clásica, aquí el sistema se construye y distribuye como si fuera un contenedor, pero con todo lo necesario para ser un host completo: kernel, espacio de usuario, servicios y herramientas básicas.

La idea de fondo es clara: unir el modelo distroless de Project Hummingbird con un sistema operativo completo que pueda usarse en máquinas virtuales, bare metal o incluso como host para otros contenedores. Así, se consigue un entorno coherente, fácil de actualizar y con una superficie de ataque más controlada, algo clave en entornos donde se despliegan múltiples runtimes y versiones de forma simultánea.

En el contexto de la comunidad Fedora, Hummingbird se plantea como un espacio de experimentación avanzado para sistemas de base de imagen, mantenidos de forma continua y orientados a un futuro donde los agentes de IA tengan un papel protagonista en el ciclo de vida del software. No sustituye a otras ediciones como Silverblue, Kinoite o Fedora CoreOS, pero sí abre la puerta a un modelo aún más integrado con pipelines automáticos y seguridad by design.

Project Hummingbird: el origen del enfoque distroless

Para entender Fedora Hummingbird hay que empezar por su raíz: Project Hummingbird, la iniciativa centrada en construir imágenes de contenedor minimalistas, endurecidas y con el objetivo explícito de acercarse a cero CVE. Todo el diseño de la arquitectura, desde el set de paquetes hasta las herramientas de construcción, está orientado a reducir la superficie de ataque y a automatizar la gestión de vulnerabilidades.

Lo más llamativo es la apuesta por imágenes “distroless”: no incluyen gestor de paquetes, ni shell, ni utilidades genéricas; contienen únicamente la aplicación y las dependencias estrictamente necesarias para ejecutarla. Esto evita que, al descargar una imagen de terceros, arrastres componentes innecesarios plagados de potenciales CVE que luego tienes que gestionar a mano.

La filosofía es que, cuando tiras de una imagen Hummingbird, el pipeline ya ha hecho el trabajo sucio: triage de CVE, aplicación de parches, reconstrucción y publicación de la nueva versión, de manera que te ahorras buena parte del infierno de vulnerabilidades típico de los contenedores. Además, el estado de CVE por imagen y variante se publica en tiempo casi real en el catálogo de Hummingbird, para que sepas en qué punto estás.

En estos meses de trabajo, el equipo ha montado un catálogo con 49 imágenes distroless únicas y 157 variantes, incluyendo builds FIPS y multi-arquitectura. Cubren runtimes de uso masivo como Python, Go, Node.js, Rust, Ruby, OpenJDK, .NET, además de servicios como PostgreSQL o nginx, entre otros muchos.

Catalina técnica: cómo se construyen las imágenes de Hummingbird

Detrás de este catálogo hay un pipeline basado en Konflux, diseñado para ofrecer compilaciones aisladas, reproducibles y fáciles de actualizar de manera incremental. El sistema trabaja con listas de paquetes fijadas (pinned), lo que permite reconstruir exactamente la misma imagen, controlar cambios y garantizar coherencia a largo plazo.

Para reducir el coste de las actualizaciones, el equipo ha desarrollado chunkah, una herramienta que permite descargar únicamente las partes modificadas de una imagen, evitando tener que volver a bajar el conjunto completo en cada actualización. Es un enfoque muy práctico en entornos donde se despliegan imágenes constantemente en clusters o nubes híbridas.

La seguridad es un pilar: las imágenes se escanean de forma continua con Syft y Grype, detectando vulnerabilidades en cuanto son reportadas y aplicando parches en cuanto están disponibles aguas arriba. En el momento en que un fix aterriza en el proyecto correspondiente, el pipeline desencadena el rebuild, ejecuta las pruebas y publica la nueva imagen.

Otra pieza clave es la relación con Fedora Rawhide: más del 95 % de los paquetes de cada imagen Hummingbird vienen directamente de Fedora Rawhide, sin modificar. Cuando Rawhide aún no incluye una versión lo bastante nueva, el sistema tira directamente de upstream, y el equipo colabora remontando cambios de vuelta a Fedora, cerrando el círculo entre la experimentación y la distribución base.

El llamado “Hummingbird factory” compila los paquetes de forma que cada uno tenga identidad propia, ciclo de vida independiente, política de parches diferenciada y su propio feed de vulnerabilidades, mantenido por el equipo de Product Security de Red Hat. Cada paquete va acompañado de datos de vulnerabilidad en formato legible por máquina que indican no solo qué CVE existen, sino cuáles afectan realmente a un workload concreto.

Del contenedor al sistema operativo: Fedora Hummingbird como OS en imagen

Las mismas dificultades de seguridad y mantenimiento que se han identificado en el espacio de usuario también aparecen en la capa de sistema operativo. Por eso, el siguiente paso lógico de Project Hummingbird ha sido aplicar este mismo enfoque al host: nace así Fedora Hummingbird como sistema operativo completo en forma de imagen OCI.

La imagen de Fedora Hummingbird está disponible públicamente en quay.io/hummingbird-community/bootc-os, y se construye con el mismo pipeline Konflux y el mismo bloqueo hermético de RPM que el resto del catálogo Hummingbird. A día de hoy ya soporta arquitecturas x86_64 y aarch64, lo que la hace válida tanto para servidores tradicionales como para nuevos entornos ARM.

El objetivo es que esta imagen pueda ejecutarse en contenedores, máquinas virtuales y despliegues bare metal, con un comportamiento consistente en todos los casos. Eso encaja con la iniciativa de Fedora de contenedores arrancables (bootable containers), que planteó que el propio sistema operativo se entregue como una imagen de contenedor más, con un modelo de actualización atómica y retroceso en caso de problemas.

En este diseño, la raíz del sistema de ficheros es de solo lectura, mientras que todo el estado modificable vive en /var y /etc, completamente separado del contenido de la imagen del sistema. Esta separación reduce la deriva de configuración, elimina estados de actualización parcial y hace que los rollbacks sean fiables.

El kernel ARK y la integración con el proyecto CKI

Bajo el capó, Fedora Hummingbird se apoya en ARK (Always Ready Kernel), procedente del proyecto CKI (Continuous Kernel Integration), que sigue de cerca el mainline de Linus Torvalds. Este kernel ya se utiliza hoy en Fedora, pero en Hummingbird toma un protagonismo clave como base de un sistema que se actualiza de forma continua.

El gran valor de CKI es que no solo ofrece una configuración de kernel cuidadosamente curada, sino todo un marco de ingeniería y pruebas alrededor de un flujo de kernel de alta velocidad. Esto permite adoptar rápidamente nuevas funcionalidades del kernel principal sin perder de vista la estabilidad, un equilibrio complicado cuando se apuesta por la velocidad de upstream.

Gracias a esta combinación, Fedora Hummingbird puede ofrecer un entorno siempre a la última en cuanto a kernel, pero con un nivel de testeo automatizado difícil de conseguir en modelos más manuales. Para los desarrolladores que dependen de nuevas capacidades del kernel (por ejemplo, en contenedores, redes, almacenamiento o soporte de hardware reciente), este enfoque resulta especialmente atractivo.

Fedora Hummingbird Linux: distribución rolling para agentes y desarrolladores de IA

Red Hat define Fedora Hummingbird Linux como un sistema operativo Linux rolling-release, nativo de contenedores, concebido para “builders” de la era agentic: desarrolladores humanos y agentes de IA que necesitan desplegar entornos de forma casi instantánea. La clave está en que evita los ciclos clásicos de lanzamiento y los bloqueos de seis meses o más, abrazando la actualización continua desde comunidades upstream.

Uno de los puntos más diferenciadores es que Hummingbird se diseña para que sean los propios agentes de IA quienes lo elijan en la fase de experimentación. En un escenario donde un agente debe levantar un entorno rápidamente, cualquier registro, formulario o verificación manual supone un atasco. Por eso, Fedora Hummingbird Linux se puede descargar sin registro, con pulls anónimos pensados para despliegues automatizados en nubes híbridas y entornos de laboratorio.

Este modelo convierte a Hummingbird en una especie de “sistema operativo por defecto” para agentes cuyo único objetivo es poner en marcha un entorno de pruebas lo antes posible. Desde ahí, la ruta natural apunta hacia entornos de producción gobernados sobre Red Hat Enterprise Linux y OpenShift Virtualization, donde ya entra en juego el soporte empresarial clásico.

En palabras de la propia Red Hat, el mercado Linux se ha bifurcado: los equipos de operaciones necesitan la estabilidad a décadas de RHEL, mientras que los creadores (humanos y agentes) piden velocidad de upstream y flujos de trabajo basados en imágenes. Fedora Hummingbird Linux se sitúa precisamente en ese segundo extremo, como plataforma de referencia para el software que construirá el futuro empresarial.

Una fábrica de software “lights out” potenciada por agentes de IA

Una de las novedades más llamativas es que gran parte del mantenimiento y la integración de nuevas funcionalidades en Fedora Hummingbird Linux se realiza mediante agentes de IA, con supervisión humana. Red Hat describe el proceso como una “software factory” de tipo lights out, es decir, altamente automatizada y capaz de funcionar prácticamente sin intervención directa.

Esto permite que la distribución avance al ritmo del ecosistema de IA, algo imposible de igualar con empaquetado manual tradicional. La combinación de agentes que automatizan tareas repetitivas (triage de CVE, generación de parches, integración de nuevas versiones) y revisiones humanas en puntos críticos busca equilibrar velocidad y seguridad.

Desde un punto de vista de seguridad, Hummingbird se apoya en la misma infraestructura automatizada y los pipelines Konflux que sustentan las Red Hat Hardened Images. Esto significa que los lenguajes, runtimes, bases de datos y herramientas que se sirven desde estas imágenes vienen libres de CVE conocidos y acompañados de completas SBOM (Software Bill of Materials), algo muy valorado en auditorías de cadena de suministro.

Onboarding sin fricción y ruta hacia la producción empresarial

En la llamada “era agentic”, la primera decisión sobre qué sistema operativo usar ya no la toma siempre una persona: un agente de IA puede elegir la distribución durante la fase de prueba de un proyecto. Si ese agente se topa con registros, licencias o muros de acceso, se frena la innovación. Fedora Hummingbird Linux nace para esquivar esos frenos.

Por eso, la distribución permite pulls anónimos y soporte para despliegues ultra rápidos, eliminando las paredes de registro que suelen frenar a los agentes y a los flujos CI/CD muy automatizados. De esta forma, se convierte en una opción tremendamente cómoda para laboratorios, prototipos y pruebas de concepto en la nube.

Red Hat, no obstante, no se queda solo en el experimento: planea ofrecer un modelo de Cooperative Community Support asociado a la suscripción de Red Hat, de modo que los usuarios de Hummingbird puedan encontrar y aprovechar con rapidez los recursos de la comunidad y, al mismo tiempo, conectar con el ecosistema de soporte empresarial.

La visión a medio plazo es que Hummingbird actúe como puerta de entrada “sin peajes” desde el portátil del desarrollador hasta las pruebas serias en la nube, y de ahí, sin necesidad de migraciones traumáticas, al mundo RHEL y OpenShift para cargas de trabajo de producción. Así, se cubre todo el trayecto: experimentación libre, consolidación y, finalmente, despliegue gobernado.

Diferencias entre Fedora Hummingbird Linux y Red Hat Desktop orientado a IA

Durante el mismo Red Hat Summit se presentaron dos propuestas de escritorio Linux diferentes para el mundo de la IA: el nuevo Red Hat Desktop, centrado en desarrolladores con un entorno gobernado, y Fedora Hummingbird Linux como opción libre y rolling para builders y agentes. Aunque se complementan, juegan papeles distintos.

El nuevo Red Hat Desktop se basa en la build de Red Hat de Podman Desktop, con el objetivo de facilitar la creación, gestión y despliegue de contenedores en Linux, macOS y Windows. Está construido sobre Red Hat Hardened Images y Red Hat Trusted Libraries, ofreciendo un enfoque muy fuerte en seguridad y en alineación con entornos OpenShift.

En ese escritorio, OpenShift Dev Spaces proporciona un marco extensible para integrar asistentes de IA directamente en el IDE en la nube. Incluye un avance técnico del asistente de código AWS Kiro, además de integraciones con Microsoft Copilot, Claude CLI, Cline, Continue, Roo y otros. El mensaje es claro: desarrollar con el asistente que prefieras, ya sea propietario u open source.

Otro elemento interesante es Kaiden, una solución open source para aislar agentes de IA en sandboxes. Esto permite probar agentes y sus acciones en el propio equipo local minimizando el riesgo de que una decisión errónea de un agente acabe desbaratando el sistema anfitrión. Para quienes experimentan mucho con agentes autónomos, es un salvavidas.

Red Hat Advanced Developer Suite incorpora además capacidades de inteligencia de exploits impulsadas por IA, que ayudan a entender si una vulnerabilidad conocida en el código generado por IA afecta realmente a un entorno de ejecución concreto. Así, se puede priorizar la corrección y mitigación en función del riesgo real, no solo de la existencia del CVE.

Mientras tanto, Fedora Hummingbird Linux se posiciona como una distribución gratuita, “free as in beer y free as in freedom”, rolling-release, pensada como sistema operativo por defecto para agentes y flujos de trabajo automatizados. No se rige por ciclos de lanzamiento congelados, sino que entrega actualizaciones desde upstream en cuanto están listas.

Red Hat planea además que Fedora Hummingbird Linux se ofrezca como opción por defecto en proveedores de nube centrados en desarrolladores, esos entornos típicos donde se inician pequeños proyectos personales o pruebas de concepto. Red Hat Desktop, por su parte, actúa como el entorno de desarrollo gobernado que refleja mejor la producción sobre RHEL y el resto de la familia Red Hat AI.

Relación con Fedora, Fedora CoreOS y la comunidad

Fedora Hummingbird no nace aislada: múltiples miembros del equipo Hummingbird ya son contribuidores y mantenedores de paquetes en Fedora, incluyendo piezas fundamentales como Podman y otras herramientas de contenedores críticas para el ecosistema Linux, además de parte del equipo detrás de Fedora CoreOS.

Los trabajos en contenedores arrancables de Fedora (bootable containers) sentaron las bases técnicas de Fedora Hummingbird. Muchas de las personas implicadas en esa iniciativa siguen ahora empujando el proyecto Hummingbird, pero con una visión más amplia: consolidar un sistema operativo completo entregado como imagen.

La intención declarada es integrar Hummingbird dentro del Proyecto Fedora para que pueda crecer y beneficiarse del mismo ecosistema comunitario. De hecho, el pipeline de Hummingbird ya construye y publica un conjunto de imágenes basadas íntegramente en Fedora Rawhide en quay.io/organization/hummingbird-rawhide, lo que refuerza la conexión.

Parte del trabajo actual se centra en reducir la mezcla entre RPM construidos por Hummingbird y paquetes estándar de Fedora dentro de la imagen, para alinear completamente la base tecnológica. Es justo en este punto donde la colaboración de la comunidad resulta más valiosa, tanto para pulir el modelo como para extenderlo a nuevos escenarios.

Además, el equipo ya está llevando de vuelta a Fedora optimizaciones específicas para contenedores, correcciones encontradas en archivos .spec y mejoras que benefician al conjunto de la distribución. El feed de vulnerabilidades que acompaña a los paquetes Hummingbird también se considera una posible aportación interesante al resto del ecosistema Fedora.

Estado actual, prototipos y ecosistema alrededor de Hummingbird

La imagen Fedora Hummingbird bootc OS ya arranca hoy y puede probarse sin necesidad de registros, suscripciones ni herramientas de gestión de licencias como subscription-manager. El código está público, el pipeline está activo y el equipo anima a que más gente se suba al carro para someter el sistema a prueba real.

Existen ya prototipos de escritorios y bases estilo CoreOS sobre Hummingbird, impulsados por parte de la comunidad y por desarrolladores ligados a proyectos como Universal Blue. Se han creado imágenes base tipo “CoreOS Desktop” montadas en un día a partir de RPM de Fedora, que arrancan correctamente y sirven como prueba de que el enfoque es viable y está más cerca de la realidad de lo que parece.

En este contexto, se han explicado cambios de planes en proyectos comunitarios, como el abandono de esquemas de ramas stable→testing→next en favor de ramas de testing puntuales y un foco más decidido en imágenes selladas y Hummingbird. La idea es que este nuevo ecosistema atraerá a un perfil de contribuidor entusiasta por experimentar con modelos de sistema operativo de nueva generación.

La comunidad ya discute activamente estas ideas en hilos específicos, grupos de interés especial (SIG) y canales de conversación abiertos. El ambiente es el habitual de Fedora: mucha experimentación, debate técnico y una invitación explícita a que cualquiera con ganas se involucre, ya sea probando imágenes, reportando bugs o contribuyendo código.

Cómo empezar a probar Fedora Hummingbird hoy

Para quienes quieran trastear desde ya, el equipo propone un flujo de arranque rápido en máquina virtual usando Podman, bootc-image-builder y virt-install, aprovechando la imagen disponible en Quay.

Los pasos generales consisten en tirar de la imagen bootc OS de Hummingbird desde quay.io usando podman, ejecutar a continuación el contenedor de bootc-image-builder con los volúmenes adecuados para que genere una imagen qcow2 con sistema de ficheros ext4, y colocar esa imagen en la ruta de almacenamiento de libvirt.

Después, renombrando el fichero disk.qcow2 a un nombre más descriptivo y usando virt-install con parámetros sencillos (memoria, vCPUs, disco, red y gráficos VNC), se puede levantar rápidamente una máquina virtual Fedora Hummingbird. No es un instalador tradicional; básicamente estás arrancando directamente una imagen ya ensamblada.

A partir de ahí, se anima a probar el sistema, revisar su comportamiento, validar actualizaciones y reportar cualquier comportamiento extraño. El feedback es especialmente valioso en estas primeras fases, cuando aún se afina la integración entre el mundo Fedora tradicional y el de las imágenes Hummingbird.

Participar, contribuir y futuro del proyecto

Quien se anime a ir más allá de la simple prueba puede abrir issues, sugerir mejoras o enviar contribuciones directamente en el repositorio del proyecto, que hoy vive en gitlab.com/redhat/hummingbird/containers. Uno de los próximos pasos previstos es precisamente migrar y asentar el proyecto dentro de la propia infraestructura de Fedora.

Además, existen sesiones de iniciación y encuentros impulsados por el SIG relacionado con Hummingbird, donde se explica el modelo técnico, se resuelven dudas sobre el pipeline, la seguridad o la integración con herramientas como Podman, y se coordinan esfuerzos entre Red Hat y la comunidad Fedora.

A nivel de visión, se espera que Fedora Hummingbird se convierta en el laboratorio donde la comunidad prueba nuevos modelos de sistemas de base de imagen y mantenimiento continuo, antes de que esas ideas acaben influyendo en el resto del ecosistema Linux. Fedora siempre ha jugado ese papel de “banco de pruebas” de tecnologías que luego acaban dominando el panorama empresarial.

En conjunto, Fedora Hummingbird y su ecosistema asociado dibujan un futuro en el que los sistemas operativos se construyen y mantienen igual que los contenedores modernos: imágenes minimalistas, pipelines automáticos, seguridad integrada y ciclos de actualización que siguen el ritmo frenético del software de hoy, tanto para desarrolladores como para agentes de IA que necesitan entornos listos al vuelo.

from Linux Adictos https://ift.tt/JtUBV4g
via IFTTT