Un error de canal manda seis fallas del kernel a la lista abierta de desarrollo, un cambio de algoritmo acelera la recuperación de memoria y Fedora 45 confirma que no llega antes de noviembre.
El fabricante de ciberseguridad envió seis reportes de fallas sin parchear a la lista abierta del núcleo en vez del canal privado, y Greg Kroah-Hartman respondió pidiendo explicaciones por cada caso.
El fabricante de ciberseguridad Trend Micro, a través de su Iniciativa Día Cero (ZDI), envió por error varios reportes de fallas sin parchear del kernel de Linux a la lista pública de desarrollo (LKML) en lugar del canal privado de seguridad, según reportó Phoronix el 22 de octubre. Entre los casos expuestos figuran ZDI-CAN-33549, una ejecución remota de código en el protocolo SMB Direct por un desbordamiento de enteros con puntaje CVSS de 9.0, y ZDI-CAN-33774, una condición de carrera en el módulo KSMBD -el servidor SMB integrado en el kernel- con el mismo puntaje. La lista también incluye ZDI-CAN-34068, una escritura fuera de límites en el controlador gráfico VMWGFX; ZDI-CAN-34076, un recurso sin inicializar en el subsistema de almacenamiento en red NVMET que puede filtrar información, y ZDI-CAN-32005, un desbordamiento de pila en la ruta de consultas DNS de dominio de búsqueda, reportado un día antes que el resto. El mantenedor Greg Kroah-Hartman respondió públicamente a cada reporte para preguntar por qué había llegado a la lista abierta en vez de la dirección de seguridad reservada del kernel, según la misma nota de Phoronix. El procedimiento estándar del proyecto exige que las fallas sin corregir se reporten en privado para dar tiempo a desarrollar un parche antes de que la información quede visible para cualquiera, incluidos posibles atacantes; publicarlas en la lista pública salta ese margen de maniobra. Ninguna de las fallas tenía parche fusionado en la rama principal al momento del reporte, aunque ZDI-CAN-33367 -un problema de copia cero en el manejo de paquetes de red (skbuff) que permite escalamiento de privilegios local- ya contaba con una corrección en camino porque otra fuente había reportado el mismo caso antes. Phoronix no precisa si Trend Micro ofreció una explicación del error de canal, y la información de esta nota proviene únicamente de ese medio, sin confirmación cruzada en otro outlet al cierre de esta edición. Oficinas costarricenses que combinan equipos Windows y Linux suelen usar el módulo KSMBD para compartir archivos sin instalar Samba por separado, de modo que quedan expuestas en teoría hasta que sus distribuciones reciban el parche correspondiente; no hay reportes de explotación activa en el país ni fuera de él al cierre de esta edición.
El 27 de octubre pasó sin que Fedora 45 saliera, confirmando que la fecha que algunas coberturas -entre ellas Linuxiac, el 20 de octubre- habían dado como el nuevo objetivo tras el primer veredicto de "no-go" ya no aplica. El objetivo oficial del proyecto sigue siendo el 3 de noviembre, según el segundo comunicado de "no-go" que la coordinadora de lanzamientos Aoife Moloney envió la semana pasada y que Phoronix y Warp2Search reportaron el 22 de octubre. Los dos veredictos consecutivos son inusuales en el calendario de Fedora: el primero, del 15 de octubre, ocurrió porque el equipo de calidad no tuvo ninguna candidata lista para evaluar; el segundo, por fallos bloqueantes que incluyen el certificado comprometido de la autoridad eMudhra todavía presente en el almacén de confianza del sistema y una imagen de Fedora Server para AArch64 que excede el tamaño máximo permitido, según Phoronix. Fedora es la base de desarrollo de Red Hat Enterprise Linux, así que una base inestable en esta fase tiende a filtrarse, meses después, hacia la rama empresarial que sí usan bancos y entidades de gobierno. La próxima reunión de confirmación es este jueves 29 de octubre; si el equipo de calidad certifica una candidata con el certificado de eMudhra corregido, el 3 de noviembre se mantiene como fecha firme. Costa Rica no tiene instituciones públicas ni bancos que dependan de Fedora en producción -el Gobierno y la banca local usan versiones estables de Red Hat Enterprise Linux o Ubuntu Server que heredan estos cambios muchos meses después-, por lo que el nuevo aplazamiento no tiene impacto inmediato en el país.
El núcleo Linux 7.4 cambió el algoritmo de búsqueda que usa su asignador temprano de memoria física ("memblock") durante el arranque, pasando de una búsqueda lineal a una búsqueda binaria, según reportó Phoronix el 24 de octubre. El propio reporte cita cifras distintas para la mejora en la recuperación temprana de memoria del mecanismo KHO ("kernel handover", el traspaso de memoria entre el kernel saliente y el entrante durante una actualización en caliente): un pasaje habla de una caída de unos 268 segundos a unos 50 milisegundos, y otro, de 238 segundos a la misma cifra final; Phoronix no aclara cuál de las dos mediciones es la definitiva. El mecanismo KHO permite que un servidor conserve el estado de la memoria al pasar de un kernel a otro sin reiniciar por completo el hardware, una técnica que usan sobre todo operadores de centros de datos y proveedores de nube para aplicar actualizaciones del núcleo con el menor tiempo de interrupción posible. Una búsqueda lineal recorre un bloque de memoria a la vez hasta encontrar el que necesita; la binaria divide el espacio de búsqueda a la mitad en cada paso, por lo que su ventaja crece exactamente en los servidores con más memoria instalada. El cambio todavía está en la fase de desarrollo del ciclo 7.4 y debe pasar varias candidatas de prueba antes de llegar a una versión estable; la información de esta nota proviene únicamente de Phoronix, sin cobertura cruzada confirmada al cierre de esta edición. Costa Rica no opera centros de datos de la escala que más se beneficia de este cambio, pero los proveedores de nube que alquilan cómputo a empresas ticas desde zonas francas y centros regionales sí dependen de actualizaciones de kernel con el menor tiempo de interrupción posible, por lo que el efecto, aunque indirecto, no es nulo.
La propuesta, enviada como solicitud de comentarios por el ingeniero de Intel Dave Hansen, exige el mecanismo FRED de entrega de eventos y por ahora solo funcionaría en procesadores recientes de Intel y AMD.
El ingeniero de Intel Dave Hansen envió el 22 de octubre una serie de parches en fase de solicitud de comentarios (RFC) para extender al espacio del kernel la protección de pilas sombra ("shadow stacks"), según reportó Phoronix. La técnica, que ya protege procesos de espacio de usuario desde Linux 6.6 mediante la extensión de seguridad CET de Intel, guarda una copia paralela de las direcciones de retorno de cada función para detectar si un atacante sobrescribió la pila normal con una dirección falsa -una de las formas más comunes de explotar errores de memoria. La serie actual, calificada por el propio Hansen como una prueba de concepto para discutir cómo debería verse una futura fusión, depende de FRED ("Flexible Return Event Delivery"), un mecanismo que limita el soporte a los procesadores Intel Panther Lake en adelante o AMD Zen 6 en adelante, según Phoronix. La dependencia de hardware tan reciente es la razón por la que Fedora, que ya aprobó activar por defecto las pilas sombra de espacio de usuario, tuvo que mover ese cambio de la versión 45 a la 46 -prevista para la próxima primavera boreal-, en parte por problemas de compatibilidad con controladores de NVIDIA y paquetes de Python, según un reporte separado de Phoronix del 31 de julio. La serie RFC no tiene fecha de fusión ni versión objetivo todavía; el propio Hansen pidió orientación sobre el diseño antes de convertirla en parches formales. Costa Rica importa por canales de retail y zonas francas los procesadores Intel y AMD de gama alta que esta protección necesitaría -Intel mantiene en Belén una planta de ensamblaje y prueba con miles de empleados-, pero ningún equipo con los chips requeridos (Panther Lake o Zen 6) está todavía a la venta en el país.
El núcleo Linux retira el controlador Binder escrito en C -el mecanismo de comunicación entre procesos que usa Android para que las aplicaciones y los servicios del sistema se hablen entre sí- en favor de la versión reescrita en Rust, según reportó Phoronix. El ingeniero de Google Carlos Llamas propuso el parche, que elimina unas 11.000 líneas de código, y Greg Kroah-Hartman lo recogió para el árbol char-misc rumbo a la versión 7.4 del kernel. Llamas describe en el propio mensaje del parche que el controlador en C se volvió difícil de mantener durante los quince años que lleva en el árbol del kernel, según recoge WindowsForum. El controlador Binder en Rust llegó al kernel en la versión 6.18 junto al de C, pensado como un periodo de transición mientras se validaba que la nueva versión alcanzara la misma funcionalidad y un rendimiento igual o mejor, de acuerdo con la cobertura previa de Phoronix sobre esa versión. Que Google, el principal responsable de Binder porque Android depende de él en cada arranque, respalde ahora el retiro completo del código en C equivale a declarar terminada esa transición: Rust pasará a ser la única implementación de Binder que reciban los kernels futuros. El parche todavía debe pasar por las candidatas de prueba del ciclo 7.4 antes de llegar a una versión estable, y de ahí a los fabricantes de teléfonos que empaquetan sus propios kernels de Android. Costa Rica no fabrica teléfonos, pero es uno de los mercados de América Central con más líneas Android activas y alberga una comunidad de desarrollo de aplicaciones móviles que eventualmente compilará y probará contra kernels que ya no incluyan el Binder en C.
— El cambio, propuesto por el ingeniero de Google Carlos Llamas y recogido por Greg Kroah-Hartman para el árbol char-misc, retira unas 11.000 líneas que el autor describe como difíciles de mantener durante quince años.
La Fundación Linux publicó el boletín de octubre con nueve reportes nuevos de su brazo de investigación, LF Research. Dos destacan por su alcance: un informe de aniversario que calcula que el kernel Linux corre hoy en 4.000 millones de dispositivos Android, más de 200 millones de servidores y las 500 supercomputadoras del ranking mundial Top500, y la novena edición anual de "State of OSPOs", elaborada junto al TODO Group, que examina cómo las oficinas de programas de código abierto están definiendo políticas de gobernanza para el código generado por inteligencia artificial. Un tercer reporte, hecho junto a Red Hat, Futurewei, OpenSSF y LF AI & Data, estudia cómo las herramientas de IA generativa están cambiando el trabajo diario de quienes mantienen proyectos de código abierto -el mismo debate que esta categoría viene cubriendo desde la semana pasada con el parche de Omarchy que una herramienta de IA calificó como listo para fusionar pero que el mantenedor humano todavía no había aprobado. El boletín también reporta que la organización financiera FINOS puso en marcha OSERA, su proyecto de normas de código abierto para la banca, con el respaldo de Deutsche Bank, Goldman Sachs, Morgan Stanley, NatWest y RBC. La Fundación no fija una fecha única de publicación para los nueve reportes -cada uno sigue su propio calendario- y el próximo evento grande es KubeCon + CloudNativeCon Norteamérica, del 9 al 12 de noviembre en Salt Lake City. El efecto directo sobre las empresas costarricenses de desarrollo de software es difuso: varias trabajan como proveedoras de clientes que sí exigen políticas de gobernanza de IA en su cadena de suministro de código, pero no hay cifras públicas de cuántas firmas ticas ya las implementan.
El 27 de octubre combinó una filtración por error de seis fallas del kernel a la lista pública de desarrollo, un cambio de algoritmo que recorta a unos 50 milisegundos la recuperación temprana de memoria durante actualizaciones en caliente, una propuesta de Intel para llevar las pilas sombra al espacio del kernel, el retiro completo del controlador Binder en C a favor de Rust, la confirmación de que Fedora 45 no saldrá antes del 3 de noviembre y el boletín de aniversario de los 35 años de la Fundación Linux. Sobre Omarchy, el personaje de la semana de esta categoría, no hubo noticia nueva en las últimas 24 horas: el desarrollo más reciente confirmado sigue siendo la expansión a equipos ARM con Snapdragon X y Nvidia N1X que Phoronix reportó el 20 de octubre con la candidata 4.5.0-rc1. Ningún hecho del día tuvo epicentro en Costa Rica.