Linus Torvalds publica el segundo RC del kernel 7.1 mientras las distribuciones completan el ciclo de actualizaciones post-Copy Fail; el nuevo NTFS con escritura completa se consolida como una de las grandes adiciones del ciclo.
El segundo Release Candidate del kernel 7.1 cierra la primera semana de pruebas con un historial de cambios más pequeño de lo habitual, lo que sugiere un ciclo relativamente limpio.
Linus Torvalds publicó este domingo 3 de mayo el segundo Release Candidate del kernel Linux 7.1. Según el anuncio en la lista kernel-announce, el diff de rc2 es notablemente más pequeño que el de rc1 —aproximadamente 180 commits frente a los 13.000 del rc1— lo que Torvalds describió como «un buen augurio para el ciclo». La mayor parte de las correcciones apuntan a los drivers AMD GPU, donde la actualización masiva de headers del rc1 (que representó el 25% del parche total) introdujo regresiones menores en configuraciones multi-GPU con tarjetas Radeon RX 9000; y al nuevo subsistema NTFS, donde se corrigieron dos casos de corrupción de metadatos en sistemas con clústeres grandes. El rc1 cerró la ventana de merge el 26 de abril con aproximadamente 13.000 commits no-merge, de los cuales unos 3.200 correspondían al bulk sync de headers de registros de GPU de AMD —una deuda técnica acumulada desde el ciclo 6.x que el equipo de AMD decidió liquidar en un solo commit masivo. El resto del rc1 distribuyó parches en redes, sistemas de archivos, memoria y núcleo core del kernel. Si el ciclo mantiene su ritmo actual sin regresiones graves, la versión estable 7.1 podría llegar el domingo 7 de junio, asumiendo RC7 como último candidato. Para los equipos de sistemas costarricenses, especialmente los que administran servidores con GPUs AMD para cargas de trabajo de inteligencia artificial —una configuración cada vez más común en empresas de la Zona Franca de Cartago— la corrección de regresiones en los drivers AMD GPU de rc2 es relevante para evaluar cuándo migrar a 7.1 en producción.
El kernel 7.1 incluye un nuevo subsistema NTFS que reemplaza al módulo ntfs3 de Paragon, incorporado en 2021 como solución provisional. La nueva implementación, que llevó cuatro años de desarrollo por parte de ingenieros del proyecto Tuxera y contribuidores independientes, usa el framework iomap —el mismo que usan ext4, XFS y btrfs— para la escritura en bloque, lo que permite escritura diferida (delayed allocation), checksum de metadatos opcionales y soporte correcto para clústeres de hasta 2 MB. El módulo legado ntfs3 de Paragon se mantiene por compatibilidad pero quedará marcado como deprecated a partir de 7.2. La implementación anterior tenía dos problemas conocidos: no usaba iomap (lo que hacía más difícil añadir journaling) y su manejo de las transacciones de metadatos de NTFS era incompleto, lo que causaba corrupción silenciosa en algunos escenarios de escritura concurrente. La nueva implementación corrige ambos y pasa el 100% de la suite de pruebas ntfsprogs. El ángulo contrario es real: Paragon publicó una nota en su lista de correo señalando que la nueva implementación aún no soporta compresión NTFS transparente ni las extensiones de seguridad de Windows Server 2022, funcionalidades que su módulo ntfs3 sí tiene aunque de forma incompleta. Para administradores ticos que gestionan entornos híbridos Linux-Windows —frecuentes en instituciones del sector público que mantienen servidores de archivos con NTFS por compatibilidad con clientes Windows— la nueva implementación es la primera en la que Linux puede montar y escribir en particiones NTFS con confianza real en producción, sin depender del espacio de usuario de ntfs-3g.
La semana 18 de 2026 (30 de abril–3 de mayo) cerró con rondas de parches de SUSE para openSUSE Tumbleweed, Leap 15.6 y SLE Backports; AlmaLinux para las versiones 8, 9 y 10; y Ubuntu para las series 24.04 LTS y 22.04 LTS. Los paquetes afectados más frecuentes: Python (múltiples CVEs de parsing de headers HTTP), sudo (CVE de escalación de privilegios de baja severidad en configuraciones no estándar), Firefox y Chromium (actualizaciones de seguridad de rutina) y el kernel Linux con el backport de CVE-2026-31431 (Copy Fail) para las distribuciones que aún no tenían el parche de la semana pasada. La cadencia de parches post-Copy Fail ha sido la más densa en lo que va de 2026 según linuxsecurity.com: en siete días se registraron 47 avisos de seguridad entre las distribuciones principales, frente a un promedio de 18 por semana en marzo.
cat /feed/kernelamdgpu.md
> El elemento más inusual del rc1 del kernel 7.1 fue un commit único del equipo de AMD que actualizó aproximadamente 2.500 archivos de headers de registros de GPU —los mapas de registros de hardware que los drivers usan para comunicarse con las tarjetas gráficas. El commit, descrito por Torvalds en el correo del rc1 como «grande pero mecánico», consolida en el árbol del kernel los headers de todas las arquitecturas de GPU AMD desde RDNA 2 hasta RDNA 4, cerrando una deuda técnica en la que muchos headers desactualizados convivían con código de driver actualizado. El tamaño del diff —más de 600.000 líneas añadidas o modificadas— es técnicamente la segunda mayor actualización del árbol del kernel en un solo commit en la historia del proyecto, después del merge de btrfs en 2009. La consecuencia práctica para usuarios de Linux con GPUs AMD: el driver AMDGPU del 7.1 tendrá mejor alineación entre los headers internos y el firmware, lo que reduce el riesgo de advertencias de compatibilidad al actualizar firmware de GPU sin actualizar simultáneamente el kernel. Para desarrolladores costarricenses que usan estaciones Linux con GPUs Radeon para renderizado o cargas de ML, la recomendación es esperar a rc4 o rc5 antes de migrar a 7.1 en entornos de producción.
El parche de CVE-2026-31431 llegó a AlmaLinux en menos de 48 horas desde la divulgación coordinada; para Debian Stable tardó seis días. La diferencia revela dos filosofías de mantenimiento de kernel con implicaciones directas para la gestión de riesgo.
La respuesta al CVE-2026-31431 (Copy Fail) ofrece el análisis más concreto del año sobre cómo funcionan las cadenas de parches de seguridad en el ecosistema Linux real. AlmaLinux y Red Hat publicaron kernels parcheados el 1 de mayo —en menos de 48 horas desde el anuncio coordinado del 29 de abril—, aprovechando su infraestructura de backporting y sus equipos de seguridad internos. Ubuntu tardó 72 horas. Fedora 42, que sigue el kernel más cercano a mainline, tardó solo 36 horas porque el parche ya estaba en el árbol 7.0.y stable. Debian Stable tardó seis días porque su proceso de revisión de parches es más conservador: cada actualización pasa por tres niveles de revisión humana antes de entrar al canal de seguridad. El ángulo contrario es el que plantea el CERT/CC de Carnegie Mellon: la velocidad no es el único indicador relevante. Debian tiene un historial históricamente menor de parches que introducen regresiones en producción, mientras que dos de las distribuciones que parchearon más rápido registraron problemas menores —un bug en el módulo SCTP en AlmaLinux y una regresión en la inicialización de interfaces InfiniBand en Ubuntu— que requirieron parches adicionales en los días siguientes. La lección no es que despacio sea mejor; es que la velocidad sin revisión tiene costos. Para las organizaciones costarricenses que administran flotas Linux heterogéneas —mezclas de Ubuntu Server, RHEL y Debian en el sector bancario y de telecomunicaciones—, la semana de Copy Fail es un caso de estudio práctico para revisar sus SLAs internos de aplicación de parches críticos y alinearlos con el ciclo real de cada distribución.
El domingo 3 de mayo deja el ecosistema Linux en un estado mejor que el del viernes: el segundo RC del kernel 7.1 muestra un ciclo relativamente estable, el nuevo subsistema NTFS supera las pruebas iniciales y la semana 18 de seguridad completó la distribución de los parches post-Copy Fail en las grandes distribuciones. El trabajo técnico pendiente está claro: las regresiones de rc2 en AMD GPU y NTFS se corregirán en rc3, que Torvalds esperaría publicar el domingo 10 de mayo. Si no aparecen sorpresas, la versión estable 7.1 llegaría en la primera semana de junio. La lección de la semana es administrativa, no técnica: la respuesta al Copy Fail reveló que las organizaciones con procesos de parcheo ad hoc tardaron entre tres y diez veces más en aplicar la corrección que las que tenían pipelines automatizados de actualización de kernel con ventanas de mantenimiento predefinidas. Para los equipos de TI costarricenses —públicos y privados— la pregunta práctica que deja esta semana es cuánto tiempo les tomó aplicar el parche de Copy Fail y si ese tiempo es aceptable para el próximo CVE CVSS 7+ que llegue.