GNOME 50.4 cierra fugas de autenticación en GDM y el CVE-2026-15588 de GLib, Mesa 26.2.0 corrige una falla crítica de memoria en VA-API, Rust adopta una política formal que exige revisor para código generado por IA mientras Debian sigue sin fecha de votación, el kernel avanza en retirar la capa crypto_rng, cinco distribuciones parchan ocho fallas de seguridad esta semana, y Ubuntu marca por primera vez en 22 días trabajo en curso sobre RefluXFS, aunque solo en la versión 26.04.
El equipo de GNOME publicó el 5 de agosto de 2026 las versiones 50.4 y 49.9 del entorno de escritorio, ambas centradas en corregir fallas críticas de autenticación en GDM, el gestor de pantallas de inicio de sesión: una vulnerabilidad de path traversal, un método para sortear el bloqueo del inicio de sesión automático y una vía de denegación de servicio, según el anuncio publicado en GNOME Discourse. La actualización incluye además GLib 2.88.3, que corrige CVE-2026-15588, una falla de denegación de servicio previa a la autenticación en D-Bus, de acuerdo con la cobertura de 9to5Linux. La decisión de lanzar dos ramas en paralelo -la estable 50.4 y la anterior 49.9- muestra que el equipo de GNOME trata estas fallas de GDM como lo bastante serias para retroportarlas a una versión que muchas distribuciones todavía mantienen en producción, según Linuxiac. El resto de los cambios es deliberadamente conservador: mutter suma metadatos de masterización HDR, GNOME Shell corrige un glitch de cursor amplificado en pantallas HiDPI y gnome-keyring ahora borra las contraseñas en texto plano de la memoria antes de liberarla, pero Nautilus y GTK no cambian, en lo que el propio equipo de lanzamiento describe como una actualización pensada para estabilidad, no para funciones nuevas. GNOME no confirmó, al cierre de esta edición, un cronograma para que Fedora, Ubuntu o Debian integren esta versión en sus repositorios estables. Costa Rica no tiene cifras propias de adopción de escritorios GNOME, pero las universidades públicas y las instituciones de gobierno que corren Fedora Workstation o Ubuntu con GNOME por defecto reciben este parche de seguridad recién en el próximo ciclo de actualización de su distribución.
El equipo central de Rust adoptó el 5 de agosto una política que permite usar modelos de lenguaje para leer y revisar código, pero no para generarlo sin un revisor que acepte evaluarlo primero.
Los equipos centrales del repositorio rust-lang/rust adoptaron el 5 de agosto de 2026 una política formal sobre el uso de modelos de lenguaje en las contribuciones al lenguaje de programación Rust, según el anuncio publicado en el blog Inside Rust. La regla central distingue usos permitidos -hacer preguntas, analizar código, resumir discusiones, sugerir enfoques y revisiones privadas- de uno prohibido: abrir una contribución de código generado por IA sin que un revisor haya aceptado explícitamente evaluarla de antemano, con el uso de la herramienta declarado sin excepción, según la misma publicación recogida por Linuxiac. La política, sin embargo, aplica únicamente a los equipos que la adoptaron dentro de ese repositorio específico -no representa una postura única de todo el proyecto Rust ni de sus paquetes (crates) independientes-, según precisó la propia publicación de Inside Rust. El sitio The Ink Plots tituló su análisis "Rust Just Drew a Line Around AI Contributions -And Its Own Leadership Isn't Sure It's the Right One" ("Rust acaba de trazar una línea sobre las contribuciones de IA -y su propio liderazgo no está seguro de que sea la correcta"), y documentó dudas internas sobre si la regla es lo bastante clara para aplicarse de forma consistente entre equipos. El contraste con Debian es directo: esa distribución sigue, desde el 24 de julio, sin fecha confirmada para votar sus cinco propuestas sobre inteligencia artificial -que van de la prohibición total a un marco permisivo con condiciones-, según reportó esta sección el 5 de agosto; Rust, en cambio, ya tiene una regla activa, aunque acotada, mientras Debian continúa en fase de debate. Ni Rust ni Debian confirmaron, al cierre de esta edición, si extenderán sus reglas actuales -acotada en un caso, inexistente en el otro- al resto de sus repositorios o paquetes derivados. Costa Rica no tiene presencia en los equipos centrales de Rust, pero la comunidad tica de desarrolladores que usa el lenguaje -creciente en proyectos de fintech y sistemas embebidos- deberá declarar el uso de IA en cualquier contribución que envíe al repositorio principal bajo esta nueva regla.
El proyecto Mesa publicó el 5 de agosto de 2026 la versión 26.2.0 de su pila gráfica de código abierto, con el backend experimental de shaders llamado Jay, un módulo de codificación de instrucciones reescrito para Intel y soporte de OpenCL 3.1 en cinco controladores -Asahi, Iris, RadeonSI, LLVMpipe y Zink-, según el anuncio oficial publicado en mesa3d.org. La versión suma también soporte de mesh shaders en el controlador Vulkan NVK para tarjetas NVIDIA y Vulkan 1.4 en KosmicKrisp, el controlador para hardware Apple Silicon, de acuerdo con la cobertura de Phoronix. Entre los cambios de esta versión, GamingOnLinux destacó una corrección de seguridad que califica de crítica: escrituras de memoria sin límite ("unbounded heap writes") en el controlador Gallium VA-API, un componente que procesa video acelerado por hardware y que, sin el parche, exponía al sistema a corrupción de memoria con contenido de video manipulado. Mesa 26.2.0 es, sin embargo, una rama de desarrollo -no recomendada todavía para escritorios estables-, y el propio proyecto recomienda a los mantenedores de distribuciones esperar la versión de corrección 26.2.1 o mantenerse en la rama 26.1.x, según la misma cobertura. Mesa no confirmó al cierre de esta edición cuándo llegará la 26.2.1 con la corrección estabilizada. La comunidad tica de jugadores en Linux -la misma que esta sección documentó el 5 de agosto tras el repunte de la cuota de Linux en la encuesta de Steam- depende de estas mejoras de Mesa para el rendimiento gráfico en SteamOS y otras distribuciones orientadas a videojuegos.
cat /feed/kernellimpieza.md
El desarrollador de Google Eric Biggers avanza en retirar crypto_rng, la capa que durante años ofreció una interfaz genérica de generación de números aleatorios en el kernel Linux, ya redundante frente a DRBG y Jitterentropy.
> > git log --oneline -1 94f1bb1
> > crypto: rng - Remove old low-level rng interface
> > autor: Eric Biggers (Google) | fecha: agosto 2026
> Eric Biggers, ingeniero de Google y uno de los mantenedores del subsistema criptográfico del kernel Linux, avanzó esta semana en el retiro de crypto_rng, la capa de abstracción que durante años permitió a distintos subsistemas y controladores del kernel solicitar números aleatorios a través de una interfaz genérica, según reportaron Phoronix y Linux Journal el 4 de agosto de 2026. El commit 94f1bb1, visible en el árbol público de Linus Torvalds en GitHub, elimina la interfaz de bajo nivel de esa capa.
> > por qué importa: crypto_rng se volvió redundante frente a las interfaces DRBG (Deterministic Random Bit Generator) y Jitterentropy, que el propio kernel recomienda usar de forma directa, según la cobertura de Phoronix. Algunos controladores de generadores de números aleatorios por hardware llegaron a implementar soporte para crypto_rng, pero esa función nunca se usó en la práctica y coexistía, de forma confusa, con hw_random, la interfaz que sí manejan los controladores reales, de acuerdo con la misma fuente.
> > qué sigue: el kernel no fijó, al cierre de esta edición, la versión exacta en que el retiro completo de crypto_rng llegará a la rama estable. El cambio es interno al kernel y no afecta directamente a las aplicaciones de usuario, por lo que Costa Rica no tiene impacto local identificable más allá de la mejora general de mantenibilidad que reciben, de forma indirecta, todas las distribuciones basadas en Linux.
Cinco distribuciones Linux orientadas a servidores empresariales publicaron, en la semana que cerró el 6 de agosto de 2026, parches para ocho fallas de seguridad distintas, según el resumen semanal de LinuxSecurity. Rocky Linux y Oracle Linux corrigieron una falla de ejecución de comandos en sg3_utils -RLSA-2026-50141 y ELSA-2026-50141, respectivamente- y Rocky publicó además un parche para una falla de ejecución remota de código en FreeRDP. SUSE y openSUSE corrigieron un desbordamiento de búfer en Rsyslog y fallas de validación DNSSEC en BIND, mientras Fedora publicó una actualización de ABRT que cierra vectores de inyección de contenido y una condición de carrera. El mismo resumen documentó dos hallazgos de fuzzing en el propio kernel: un use-after-free reproducible en el controlador USB para la pantalla táctil SUR40, con pruebas de parche en curso, y una desreferencia de puntero nulo alcanzable a través de configfs y la ruta de espacio de nombres NVMe respaldada por archivos. Ninguna de las ocho fallas alcanzó cobertura destacada en medios generalistas -el propio resumen de LinuxSecurity lo señala como una semana de parches rutinarios de proveedor antes que de divulgaciones que dominen los titulares-, un patrón que contrasta con la atención mediática que sí recibió RefluXFS en julio pese a que su gravedad, CVSS 7,8, es comparable a varias de estas fallas. La información de este resumen proviene de la cobertura de LinuxSecurity, sin que esta sección haya podido confirmar de forma cruzada cada aviso individual con un segundo medio al cierre de esta edición. Instituciones costarricenses que corren distribuciones compatibles con RHEL -Rocky Linux u Oracle Linux son frecuentes en banca y sector público tico- deben aplicar estos ocho parches en su próximo ciclo de mantenimiento para cerrar las fallas de ejecución de comandos y de código remoto ya documentadas.
El rastreador de seguridad de Canonical marcó por primera vez en 22 días un movimiento en RefluXFS: el estado de 26.04 LTS pasó a 'work in progress', mientras las otras cuatro versiones LTS afectadas siguen sin parche.
El Pisuika confirmó, al consultar directamente ubuntu.com el 7 de agosto de 2026, que el rastreador de seguridad de Canonical registró el primer cambio en 22 días en el caso de CVE-2026-64600 (RefluXFS): el estado de Ubuntu 26.04 LTS pasó de "needs evaluation" a "work in progress" ("trabajo en curso"), con última actualización fechada el 6 de agosto según la propia página de Ubuntu. Las otras cuatro versiones con soporte activo y afectadas por la falla -24.04, 22.04, 20.04 y 18.04 LTS- permanecen marcadas simplemente como "vulnerable", sin indicio de trabajo en curso; 16.04 y 14.04 no están afectadas por diferencias en su versión de kernel. El movimiento llega 22 días después de que el commit 2f4acd0 corrigiera la falla en el kernel Linux oficial, el 16 de julio, y 15 días después de que Canonical fijara la prioridad de la falla en "Medium", sin cambios desde el 23 de julio. Que el primer signo de actividad aparezca únicamente en la versión más reciente -26.04, la LTS con menos instalaciones activas del parque de Ubuntu- deja abierta la duda de si Canonical prioriza por antigüedad de versión o simplemente por facilidad técnica de retroportar el parche; la compañía no ha explicado el criterio, y las versiones con más años de despliegue en producción -22.04 y 20.04- siguen sin fecha. Canonical tampoco publicó avisos de seguridad nuevos desde el USN-8620-4 del 31 de julio -siete días corridos-, según el listado oficial de ubuntu.com. Canonical no ha confirmado cuándo el estado "work in progress" de 26.04 se traducirá en un parche publicado, ni cuándo empezará a moverse el rastreador para las otras cuatro versiones vulnerables. Proveedores de hosting y entidades públicas costarricenses que operan volúmenes XFS con reflink habilitado -la misma advertencia que esta sección repite desde el 30 de julio- siguen, 22 días después del arreglo en el kernel oficial, sin una versión oficial de Ubuntu a la cual migrar para cerrar el hueco por completo.