El mantenedor de kernels estables entrega correcciones para CVE-2026-31431 en todas las ramas LTS activas; un patch experimental sienta las bases para emular chips ARM en mainframes IBM s390.
La CISA fijó el 6 de mayo como fecha límite para que las agencias civiles federales de EE.UU. parchearan CVE-2026-31431; hoy mismo Greg Kroah-Hartman publicó los parches para todas las ramas de soporte a largo plazo.
Greg Kroah-Hartman publicó el 6 de mayo las versiones estables 7.0.3, 6.18.26, 6.12.85, 6.6.137, 6.1.170, 5.15.204 y 5.10.254 del kernel Linux. Las versiones 7.0.3 y 6.18.26 contienen únicamente correcciones para usuarios de Xen, mientras que las cinco restantes incluyen los backports de los parches de CVE-2026-31431, la vulnerabilidad de escalación local de privilegios conocida como Copy Fail. El exploit público de la firma Theori, de 732 bytes, otorga una shell root con éxito del 100% en Ubuntu 24.04 LTS, Amazon Linux 2023 y RHEL 10.1 en sistemas sin parchar. La CISA había ordenado el 1 de mayo a todas las agencias civiles federales de EE.UU. aplicar el parche antes del 6 de mayo, según la directiva vinculante BOD-22-01. El ángulo contrario lo aporta Google Project Zero, que publicó el 4 de mayo un análisis señalando que el exploit requiere acceso al socket AF_ALG, bloqueado por defecto en los perfiles seccomp de contenedores con política `restricted` —incluyendo gVisor y las configuraciones estándar de containerd. Las organizaciones que ya aplican estas políticas tienen una capa de mitigación que reduce el riesgo real por debajo del nivel que sugiere la puntuación CVSS de 7.8. Para empresas costarricenses con servidores en AWS (Amazon Linux 2023) o con cargas en RHEL o SUSE, los parches están disponibles desde el 30 de abril a través de los canales de actualización estándar de cada distribución. La acción recomendada es verificar la versión del kernel instalado y confirmar que el parche está aplicado antes del cierre del día.
La mayor tanda de lanzamientos estables del año llega el mismo día que vence el plazo de la CISA para Copy Fail, cerrando el ciclo de parches de emergencia iniciado a finales de marzo.
La liberación simultánea de siete versiones del kernel en un solo día es inusual pero no sin precedente: ocurre cuando la publicación de correcciones de seguridad se sincroniza con ramas en diferentes estados de mantenimiento. Las versiones 7.0.3 y 6.18.26 llevan exclusivamente correcciones para el hipervisor Xen —un subconjunto de servidores y entornos de virtualización que requería un parche específico independiente del resto— mientras que 6.12.85, 6.6.137, 6.1.170, 5.15.204 y 5.10.254 integran los backports de Copy Fail y otras correcciones menores acumuladas en el último ciclo. El mantenedor de kernels estables subrayó en el mensaje de la lista de correo que los usuarios de ramas fuera de mantenimiento activo (es decir, anteriores a 5.10) deben migrar, ya que esas versiones no recibirán el parche. La rama 5.4, que alcanzó su fin de vida en enero de 2026, quedó fuera de esta ronda. Según el sitio endoflife.date, aproximadamente el 18% de los servidores Linux en producción a nivel global todavía ejecutan kernels que ya no reciben soporte activo. En Costa Rica, los sistemas que ejecutan kernels desactualizados en entornos de producción —una situación relativamente común en pequeñas y medianas empresas que evitan reinicios frecuentes— están expuestos a Copy Fail sin posibilidad de parchear sin migrar a una rama con soporte activo. La recomendación es auditar la versión del kernel con `uname -r` y verificar contra la tabla de versiones con soporte activo en kernel.org.
Steffen Eiden y colaboradores presentaron esta semana a la lista de correo del kernel el primer conjunto de cambios para ejecutar código ARM con asistencia de hardware en arquitectura s390.
Un conjunto de parches presentado esta semana a la lista de correo del kernel por Steffen Eiden y otros desarrolladores describe la infraestructura necesaria para ejecutar instrucciones ARM en procesadores IBM s390 mediante asistencia de hardware, aprovechando capacidades de virtualización nativas del mainframe que hasta ahora no se habían expuesto al kernel Linux. La propuesta está en estado experimental: no hay fecha de integración y está sujeta a revisión por parte de los mantenedores de las arquitecturas implicadas. El interés técnico es doble. Primero, porque el s390 tiene una historia de soporte a múltiples conjuntos de instrucciones en hardware (ya soporta z/Architecture y derivados); agregar ARM supondría un uso de esa capacidad para el ecosistema Linux. Segundo, porque abriría la posibilidad de ejecutar cargas de trabajo ARM —cada vez más frecuentes con el auge de los procesadores Apple Silicon y los chips ARM de nube— directamente en hardware mainframe de IBM sin necesidad de virtualización por software (QEMU), que tiene una penalización de rendimiento significativa. El impacto en Costa Rica es marginal a corto plazo: el mercado local no tiene instalaciones de mainframe IBM s390 en empresas medianas o pequeñas. Sin embargo, para los equipos de CCSS, ICE o Hacienda que operan infraestructura heredada en mainframes, la posibilidad de ejecutar cargas ARM modernas en el mismo hardware podría simplificar migraciones a largo plazo.
AerynOS publicó el 5 de mayo su versión 2026.05, la primera actualización del año con Linux 7.0 como kernel base en lugar de 6.18. La distribución, conocida por su sistema de paquetes atómico inspirado en Solus, actualiza también su logo y la interfaz de instalación. Según el anuncio oficial publicado en 9to5Linux, el salto a Linux 7.0 le permite a AerynOS ofrecer soporte de hardware más reciente, incluyendo los nuevos controladores Wi-Fi para chipsets MediaTek y las mejoras al soporte de GPU AMD que llegaron con ese ciclo. AerynOS no es una distribución de uso masivo, pero su adopción temprana de kernels recientes la convierte en un indicador del estado de madurez de los ciclos de desarrollo. Que 7.0 —lanzado el 12 de abril— ya sea la base de una distribución estable apenas tres semanas después es una señal de que el ciclo de 7.x está considerablemente más estable que lo que sugieren sus candidatos a versión todavía en desarrollo. El ángulo contrario: el desarrollador Remco van Hoef advirtió en el blog de la distribución que el driver de red ath12k para ciertos chips Wi-Fi Qualcomm tiene regresiones menores en 7.0 que se esperan solucionar en 7.1. Para usuarios costarricenses que buscan alternativas a Ubuntu o Fedora con actualización más rápida del kernel, AerynOS 2026.05 es una opción para equipos de escritorio con hardware reciente. La imagen ISO está disponible desde el sitio oficial de la distribución.
Greg Kroah-Hartman anunció en marzo de 2026 que los kernels 6.6 y 6.12 extenderán su soporte a largo plazo (LTS) hasta diciembre de 2027 y diciembre de 2028, respectivamente —un año adicional frente a la ventana de dos años original. La decisión se tomó tras discusiones con empresas y organizaciones que usan estas ramas en infraestructura de producción y necesitaban mayor certeza de mantenimiento antes de comprometerse a despliegues a largo plazo. Según FOSS Force, la extensión aplica también a otro mantenedor de ramas estables, Sasha Levin. Para operaciones empresariales, la extensión significa que los equipos que adoptaron 6.6 (la rama LTS anterior al ciclo de 7.x) pueden planificar un ciclo de actualización de cuatro años en lugar de dos sin riesgo de quedar sin parches de seguridad. El 6.12, como la LTS más reciente antes del ciclo 7.x, seguirá el mismo camino. El ángulo escéptico: Kroah-Hartman ha advertido repetidamente que la extensión de soporte no implica backport de nuevas funcionalidades, solo correcciones de seguridad y bugs críticos. Las organizaciones que necesiten funcionalidades de kernels más recientes seguirán necesitando actualizar. En Costa Rica, la extensión tiene valor directo para operaciones de TI del sector público y para proveedores de nube local que ejecutan infraestructura en kernels LTS: les da más tiempo para planificar migraciones sin comprometer la postura de seguridad.
Un análisis de CIQ publicado este mes documenta que el número de CVEs en el kernel Linux activamente explotados en el primer trimestre de 2026 ya supera el total de 2024. El fenómeno tiene una explicación técnica y una estructural. La explicación técnica es que subsistemas como AF_ALG —el afectado por Copy Fail— acumularon deuda técnica durante años sin revisiones de seguridad formales, y esa deuda se está pagando ahora que las herramientas de auditoría son más sofisticadas. La explicación estructural es que la práctica de usar LLMs para buscar patrones de vulnerabilidad en el árbol del kernel —documentada en el ciclo de 7.1 con el trabajo de Theori— está aumentando la tasa de descubrimiento. El ángulo que complica la narrativa es el del tiempo de respuesta: el kernel security team respondió a Copy Fail en menos de una semana desde el reporte privado, lo que sugiere que el proceso de divulgación responsable está funcionando bien. El problema no es la velocidad de parche sino el tiempo que tardan las distribuciones y los administradores en aplicar esos parches en producción. Según el Microsoft Security Blog, entre el parche del kernel y la aplicación en entornos corporativos puede pasar entre una semana y un mes, dependiendo de los procesos de aprobación de cambios de cada organización. Para el sector tecnológico en Costa Rica, el mensaje práctico es claro: las organizaciones sin sistemas automatizados de actualización de kernel (unattended-upgrades en Debian/Ubuntu, dnf-automatic en RHEL/Fedora) tienen ventanas de exposición que se miden en semanas, no en horas.
La edición del 6 de mayo cierra con tres historias paralelas en el ecosistema Linux. La primera es de respuesta de seguridad: el plazo CISA para Copy Fail venció hoy y los parches están disponibles para todas las ramas LTS activas. La segunda es de futuro técnico: el patch para emulación ARM en s390 es una de las apuestas arquitecturales más ambiciosas del ciclo de 2026, aunque todavía experimental. La tercera es de estabilidad operacional: la extensión del soporte LTS para 6.6 y 6.12 a cuatro años le da a las organizaciones más tiempo para planificar sin sacrificar seguridad. Para los equipos de TI en Costa Rica, el día de hoy tiene una tarea concreta: verificar la versión del kernel y confirmar que Copy Fail está parcheado.