El segundo candidato a versión cierra bugs de GPU AMD mientras el plazo CISA para parchear Copy Fail vence mañana en todas las agencias federales de EE.UU.
El segundo candidato de Linux 7.1 llega cuatro días después del rc1 con un foco claro en estabilidad de GPU y controladores de hardware obsoleto.
Linus Torvalds publicó Linux 7.1-rc2 el domingo 4 de mayo con un conjunto de correcciones dirigidas principalmente al subsistema de GPU AMD: se repararon regresiones en el controlador AMDGPU que afectaban a tarjetas de la serie RX 5000 y 6000, y se incorporaron mejoras al soporte de arquitectura GCN (Graphics Core Next) para hardware con varios años de antigüedad que la comunidad todavía usa activamente. El rc2 también incluye correcciones al soporte Wi-Fi para ciertos chipsets MediaTek y arreglos en el sistema de archivos btrfs relacionados con operaciones de compresión en volúmenes con subtrapas anidadas. La ventana de integración de 7.1 —el periodo en que Torvalds acepta nuevas características— cerró con 12.996 conjuntos de cambios integrados al árbol principal. Entre las incorporaciones más notables están el nuevo driver NTFS descrito por Torvalds como la "resurrección NTFS", el descarte definitivo del soporte para procesadores i486, y mejoras en el scheduler para workloads NUMA de alta concurrencia. El rc2 es la primera oportunidad que tienen los testers de confirmar que esas incorporaciones no introdujeron regresiones. Para administradores de sistemas en Costa Rica que ejecutan kernels experimentales o mainline en servidores de prueba, el rc2 es el momento ideal para identificar problemas antes de que 7.1 alcance su versión estable prevista para mediados de junio.
El veterano desarrollador Namjae Jeon trae un driver NTFS modernizado que pasa 326 xfstests contra 273 del ntfs3, y añade soporte para operaciones que la implementación de Paragon nunca tuvo.
El nuevo driver NTFS integrado en la ventana de Linux 7.1 proviene del trabajo de Namjae Jeon —el mismo desarrollador detrás del driver exFAT y del servidor de archivos KSMBD— que construyó NTFSPLUS como una evolución del antiguo driver ntfs de solo lectura que existía en el kernel desde los años 2000. La versión integrada en 7.1 es de lectura y escritura, pasa 326 xfstests (53 más que el ntfs3 de Paragon), y añade soporte para `fallocate`, `idmapped mounts` y control de permisos más granular. El driver coexistirá con ntfs3 de Paragon en el árbol de 7.1: ambos están disponibles vía Kconfig, pero las tendencias en la lista de correo del kernel sugieren que ntfs3 tiene los días contados. Los usuarios que montan particiones Windows para intercambiar archivos —un caso muy común en equipos de trabajo dual-boot— se beneficiarán de mejor rendimiento en escrituras grandes y mejor manejo de archivos comprimidos NTFS, que ntfs3 no soporta correctamente. Para equipos de desarrollo en Costa Rica que usan Linux en máquinas con particiones Windows (un escenario frecuente en entornos empresariales mixtos), el nuevo driver significa menos fricción al compartir proyectos entre sistemas operativos sin pasar por FAT32 o exFAT.
La Agencia de Ciberseguridad e Infraestructura de EE.UU. (CISA) agregó CVE-2026-31431 —la vulnerabilidad de escalación local de privilegios apodada Copy Fail— al catálogo de vulnerabilidades conocidas y activamente explotadas (KEV) el 1 de mayo, con un plazo de 72 horas para agencias federales que vence el miércoles 6 de mayo. El exploit público de 732 bytes publicado por Theori otorga una shell root con éxito del 100% en Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 y SUSE 16; los kernels parcheados son las versiones 6.6.84-LTS, 6.12.26-LTS, 7.0.3 y 7.1-rc2. El ángulo contrario lo aporta Google Project Zero, que señaló que el exploit requiere acceso al socket AF_ALG —bloqueado por defecto en los perfiles seccomp de containerd con configuración `restricted` y en gVisor. En entornos con políticas de seguridad estrictas, el riesgo real es materialmente más bajo que el que sugiere la puntuación CVSS de 7.8. La recomendación de parchear no cambia, pero las empresas que ya aplican seccomp `restricted` tienen un nivel adicional de mitigación mientras aplican el parche. Para organizaciones costarricenses con servidores en AWS (Amazon Linux 2023) o con cargas RHEL/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.
cat /feed/kernelarquitectura.md
> Con la integración de Linux 7.1, Linus Torvalds eliminó el soporte para la arquitectura i486 —los procesadores Intel de 32 bits de cuatro núcleos lanzados en 1989— por primera vez desde 2012, cuando el i386 fue descartado. El i486 dejó de venderse hace décadas y ninguna distribución Linux moderna lo soporta como plataforma objetivo, pero el código de soporte seguía en el árbol principal como herencia histórica. El mantenedor de arquitecturas x86, Ingo Molnár, argumentó que el código de soporte para i486 generaba deuda técnica sin uso práctico y añadía complejidad a las rutas de código que todos los usuarios modernos de x86 heredan.
> El cambio no afecta a ningún usuario de Linux en hardware real o virtualizado de los últimos 30 años: todos los procesadores x86 fabricados desde mediados de los noventa en adelante implementan al menos la arquitectura Pentium (i586), que Linux sigue soportando. La decisión sí cierra definitivamente la puerta a proyectos de emulación de hardware histórico que usaran el kernel mainline como base, aunque esos proyectos raramente lo hacían. La ausencia de i486 en el árbol es una señal de higiene de código más que de impacto operacional.
> En Costa Rica, sin impacto local conocido: ningún servidor, estación de trabajo ni dispositivo embebido en uso activo ejecuta un i486.
El resumen semanal publicado por 9to5Linux el 3 de mayo 2026 describe la semana más activa del ecosistema Linux en lo que va del año. Además de la apertura y cierre de la ventana de integración de 7.1 y el disclosure de Copy Fail, la semana incluyó actualizaciones de seguridad de emergencia para Ubuntu, Debian, Fedora, SUSE y Red Hat; el lanzamiento de AerynOS 2026.05 con Linux 7.0; y la publicación del análisis de Theori sobre cómo su pipeline de IA identificó CVE-2026-31431 en el árbol completo del kernel. El ángulo que el roundup destaca con más énfasis es el tiempo de respuesta del equipo de seguridad del kernel: desde el reporte privado de Theori el 23 de marzo hasta el parche público tomó menos de una semana, el tiempo más rápido para un bug de severidad alta en lo que va de 2026. El mantenedor Willy Tarreau atribuye esa velocidad a la modularidad del subsistema afectado (authencesn en AF_ALG), no a la herramienta de IA que encontró el bug. Para los equipos de seguridad en Costa Rica, la lección práctica es que un sistema de actualización automatizado (unattended-upgrades en Debian/Ubuntu, dnf-automatic en Fedora/RHEL) reduce la ventana de exposición a horas en lugar de días o semanas.
— El roundup semanal de 9to5Linux del 3 de mayo documenta una semana dominada por Linux 7.1 rc1, el parche de Copy Fail y una oleada de actualizaciones de distribuciones en paralelo.
Un análisis publicado esta semana por PBX Science sobre el ciclo de desarrollo de Linux 7.1 documenta algo que los observadores de la lista de correo del kernel llevan meses notando: por primera vez en la historia del proyecto, un número significativo de mantenedores usa herramientas de análisis asistido por IA para preclasificar parches antes de revisarlos manualmente. El caso más documentado es el de Theori, que encontró Copy Fail con un pipeline de LLM, pero el fenómeno es más amplio: al menos tres subsistemas del kernel tienen mantenedores que reportan usar modelos de lenguaje para buscar patrones de error en parches antes de la revisión de código. El debate en la lista de correo no es sobre si la IA debe usarse, sino sobre transparencia: ¿debe un mantenedor declarar que rechazó un parche parcialmente basado en análisis de IA? El maintainer de netdev Jakub Kicinski publicó una nota en abril argumentando que las herramientas de análisis son análogas a los linters —nadie declara que corrió `checkpatch.pl`— y que aplicar un estándar distinto a la IA sería inconsistente. La posición contraria, expresada por varios contribuyentes en la lista, es que los falsos positivos de un LLM tienen consecuencias distintas a los de un linter determinístico. Para empresas costarricenses que contribuyen al kernel (una comunidad pequeña pero existente, especialmente en el área de drivers para hardware industrial), el debate sobre transparencia en revisión asistida por IA llegará tarde o temprano a sus propias políticas internas de revisión de código.
La edición del 5 de mayo cierra una de las semanas más densas del año para el ecosistema Linux. Linux 7.1-rc2 confirma que el ciclo de desarrollo avanza sin regresiones mayores después de una ventana de integración que introdujo el nuevo driver NTFS, el descarte del i486 y mejoras al scheduler NUMA. El plazo CISA para parchear Copy Fail vence mañana, y el análisis del ciclo de 7.1 muestra que la IA ya es parte activa del proceso de revisión de código del kernel. Para los sistemas Linux en producción en Costa Rica, la tarea inmediata es verificar la versión del kernel instalado y confirmar que el parche de CVE-2026-31431 está aplicado antes del cierre del día.