Willy Tarreau y Greg Kroah-Hartman endurecen las reglas para reportes de fallas asistidos por IA en el kernel oficial y prohíben la etiqueta Signed-off-by a los agentes; el ataque de cadena de suministro contra el AUR de Arch Linux escala a más de 1.500 paquetes comprometidos, aunque el equipo de DevOps lo da por controlado; el kernel corrige tres fallas remotas con hasta CVSS 8,8 en GTP-U, el servidor SMB y el controlador Wi-Fi brcmfmac mientras Ubuntu tarda en aplicarlas; dos fallas de memoria más se cierran en la consola fbdev; y el rastreador de Canonical para RefluXFS no se mueve por tercer día consecutivo.
El desarrollador Willy Tarreau actualizó el 4 de agosto la documentación oficial del kernel para exigir reproductores verificados y vetar la etiqueta Signed-off-by en contribuciones asistidas por IA.
El desarrollador Willy Tarreau, con el aval del mantenedor Greg Kroah-Hartman, actualizó el 4 de agosto de 2026 tres documentos del proceso oficial del kernel Linux -coding-assistants.rst, security-bugs.rst y threat-model.rst- para endurecer las reglas sobre el uso de inteligencia artificial en la búsqueda y el reporte de fallas, según los commits publicados en el repositorio de Linus Torvalds en GitHub. La actualización fija un procedimiento obligatorio de nueve pasos para cualquier IA que participe en la caza de errores -desde documentar el commit exacto donde vive la falla hasta verificar la corrección con un reproductor antes de enviarla- y prohíbe de forma explícita que los agentes de IA agreguen la etiqueta Signed-off-by, reservada para el humano que certifica el Developer Certificate of Origin y asume la responsabilidad legal del envío. La revisión responde a un problema que los propios documentos describen sin rodeos: los reportes generados por IA "causan una sobrecarga en los mantenedores, que a veces se ven obligados a ignorar dichos reportes por su mala calidad o precisión", según el texto de security-bugs.rst. El documento suma críticas puntuales -extensión excesiva que oculta la información relevante, formato en Markdown que dificulta encontrar los datos importantes y falta de comprensión del modelo de amenazas del kernel, lo que "agrega ruido y complica el triage"- y exige que cualquier hallazgo asistido por IA se trate como público de inmediato, porque estos reportes "sistemáticamente aparecen de forma simultánea entre varios investigadores, a menudo el mismo día". La regla llega dos meses después de que Sasha Levin introdujera, el 6 de enero, la primera versión de esta documentación, y confirma que el kernel opta por permitir la IA como herramienta de asistencia -nunca como autora- mientras Rust y Debian debaten políticas similares para sus propios repositorios, según reportó esta sección el 7 y el 8 de agosto. El kernel Linux no fijó, al cierre de esta edición, una fecha para revisar de nuevo estas reglas ni un mecanismo automatizado para detectar reportes que las incumplan. Costa Rica no tiene desarrolladores identificados entre los mantenedores centrales del kernel, pero las universidades públicas y las empresas de software tico que investigan fallas de seguridad -una práctica creciente en la comunidad local de ciberseguridad- deben ahora citar un commit o una versión exacta, y no "la rama principal más reciente", si quieren que un reporte asistido por IA sea considerado válido.
El kernel Linux oficial corrigió, entre el 5 y el 6 de agosto de 2026, tres fallas de seguridad remotas de severidad alta, según los registros públicos del programa CVE. CVE-2026-64577, con CVSS 7,5, permite provocar un pánico del kernel al enviar paquetes GTP-U manipulados de 16 a 19 bytes al puerto UDP 2152, sin necesidad de autenticación ni acceso local. CVE-2026-64578, con CVSS 8,2, es una lectura fuera de límites en el servidor SMB del kernel (ksmbd) que un cliente remoto puede activar con una solicitud compuesta diseñada para leer un campo de dos bytes sin validar antes el tamaño del elemento. CVE-2026-64586, con CVSS 8,8, es un use-after-free en el controlador Wi-Fi brcmfmac que se dispara cuando el sistema no vacía correctamente una tarea de reinicio de bus al retirar el dispositivo. Las tres quedaron cerradas en las versiones estables 6.6.148, 6.12.101, 6.18.42, 7.1.6 y en la candidata 7.2-rc5, de acuerdo con los propios registros del CVE. El sitio especializado techveda.live documentó, en su resumen semanal publicado el 8 de agosto, que el kernel Linux acumuló 46 CVE nuevos en la semana del 2 al 8 de agosto, todos ya corregidos en alguna rama estable y ninguno con exploit público conocido -un patrón de divulgación rutinaria, no de emergencia, según la misma cobertura. La brecha real está en la distribución: el rastreador de seguridad de Ubuntu confirmó, al consultarlo directamente el 9 de agosto, que las tres fallas -64577, 64578 y 64586- siguen marcadas como "vulnerable" o "needs evaluation" en las versiones LTS activas de Ubuntu, con prioridad "Medium" y sin actualización desde el 7 de agosto, pese a que el kernel oficial ya las había cerrado entre tres y cuatro días antes. Canonical no confirmó, al cierre de esta edición, cuándo estos tres parches llegarán a Ubuntu en forma de imagen de kernel actualizada. Instituciones y empresas costarricenses que exponen servicios SMB (ksmbd) o levantan redes de telecomunicaciones con GTP-U -operadores móviles y proveedores de infraestructura, principalmente- deben verificar manualmente si su kernel ya incorpora los commits corregidos mientras la distribución que usan no publique el paquete actualizado.
Arch Linux considera bajo control el ataque de cadena de suministro contra el AUR (Arch User Repository) que en las últimas dos semanas escaló de 89 a más de 1.500 paquetes comprometidos, según tituló Phoronix esta semana. El equipo de DevOps de la distribución, que ya había desactivado la adopción de paquetes huérfanos el 30 de julio, suspendió el 1 de agosto de 2026 todas las subidas al repositorio -no solo las adopciones-, de acuerdo con Cybernews. El caso arrancó con el paquete openconnect-sso, cuya ruta de compilación envenenada entregaba un cargador para Linux seguido de un infostealer, un troyano de acceso remoto y un gusano que se propaga por SSH, según documentó la firma de investigación Corgea. El sitio FOSSLinux tituló su cobertura "Arch Linux AUR bajo asedio: 7 incidentes de malware en 12 meses", y documentó que este episodio de agosto es el séptimo golpe de cadena de suministro contra el repositorio comunitario en un año -no el primero ni el segundo, como sugeriría tratarlo como un hecho aislado. La cifra expone la tensión de fondo del modelo del AUR: cualquier persona puede publicar o adoptar un paquete sin verificación reforzada de identidad, y la propia documentación de Arch Linux describe ese repositorio como software para "usar bajo su propio riesgo". Suspender las subidas resuelve el vector inmediato de este ataque, pero no corrige la debilidad estructural que permitió siete incidentes en un año, según el mismo análisis de FOSSLinux. Arch Linux no confirmó, al cierre de esta edición, una fecha para reactivar las subidas y adopciones de paquetes en el AUR, ni cuántos usuarios instalaron alguno de los más de 1.500 paquetes señalados. Costa Rica no tiene cifras propias de adopción de Arch Linux, pero la comunidad tica de usuarios avanzados que mantiene paquetes propios en el AUR -la misma que esta sección instó a revisar manualmente sus instalaciones el 8 de agosto- debe ahora además verificar si alguno de los paquetes recién sumados a esa lista de 1.500 corresponde a software que tiene instalado.
cat /feed/kerneldesarrollo.md
Los desarrolladores Rik van Riel y Zizhi Wo corrigieron el 8 de agosto dos fallas de memoria en el subsistema de consola fbdev del kernel Linux.
> > git log --oneline -2 -- drivers/video/fbdev
> > e033cbf fbdev: bitblit: bound-check glyph index in bit_cursor()
> > ef76568 fbdev: Fix out-of-bounds access when rotating console after font resize
> > autores: Rik van Riel, Zizhi Wo | fecha: 8 de agosto de 2026 | mantenedor: Helge Deller
> Los desarrolladores Rik van Riel y Zizhi Wo enviaron, el 8 de agosto de 2026, dos correcciones de memoria al subsistema de framebuffer (fbdev) del kernel Linux, fusionadas el mismo día por el mantenedor Helge Deller, según el repositorio público de Linus Torvalds en GitHub. El primer parche agrega una verificación de límites al índice de glifo que usa la función bit_cursor(), para evitar que un valor fuera de rango provoque un desbordamiento al dibujar el cursor de texto en la consola. El segundo corrige un acceso fuera de límites que ocurría al rotar la consola después de cambiar el tamaño de la fuente.
> > por qué importa: fbdev es el subsistema más antiguo de manejo de framebuffer del kernel Linux, en gran medida sustituido por DRM/KMS en el escritorio moderno pero todavía activo en consolas de texto, sistemas embebidos y sesiones de arranque sin controlador gráfico completo. Un desbordamiento de memoria en el manejo del cursor o de la rotación de consola es explotable localmente en el peor de los casos, y su corrección silenciosa -sin CVE asignado ni aviso de seguridad, solo dos commits de mantenimiento rutinario- es representativa de cómo se cierra la mayoría de las fallas de memoria del kernel: como parte del flujo normal de revisión, no como respuesta a una divulgación pública.
> > qué sigue: ambos parches ya están en el árbol principal de Linus Torvalds rumbo a Linux 7.2, cuya versión estable se espera entre mediados y fines de agosto de 2026. El cambio es interno al kernel y no depende de ninguna distribución específica para llegar a producción una vez publicada la versión estable; Costa Rica no tiene impacto local identificable más allá de la mejora general de estabilidad que reciben, de forma indirecta, los sistemas embebidos y servidores ticos que aún dependen de consolas de texto basadas en fbdev.
El Pisuika confirmó, al consultar directamente ubuntu.com el 9 de agosto de 2026, que el rastreador de seguridad de Canonical para CVE-2026-64600 (RefluXFS) no registra ningún cambio desde el 6 de agosto: Ubuntu 26.04 LTS sigue siendo la única versión marcada como "work in progress", mientras 24.04, 22.04, 20.04 y 18.04 permanecen como "vulnerable", sin fecha de parche. La prioridad se mantiene en "Medium", sin cambios desde el 23 de julio -17 días-, y Canonical no publicó ningún aviso de seguridad nuevo desde el USN-8620-4 del 31 de julio: nueve días corridos, según confirmó El Pisuika al revisar el listado oficial de avisos. El commit 2f4acd0, que corrigió la condición de carrera de RefluXFS en el kernel Linux oficial, cumple 24 días fusionado en el árbol del kernel desde el 16 de julio. Es la tercera edición consecutiva en que esta sección encuentra el rastreador de Canonical exactamente en el mismo estado: ni un cambio de prioridad, ni un nuevo aviso, ni movimiento en las cuatro versiones LTS con más años de despliegue en producción. El patrón no es exclusivo de RefluXFS -el rastreador de Ubuntu tampoco había movido, hasta el 7 de agosto, las tres fallas remotas de alta severidad que el kernel oficial cerró esa misma semana, según confirmó esta sección más arriba en esta edición-, lo que sugiere una demora estructural en el ciclo de parcheo de Canonical y no un caso aislado. Canonical no ha confirmado cuándo el "trabajo en curso" de 26.04 se traducirá en un parche publicado, ni cuándo el rastreador empezará a moverse para las otras cuatro versiones vulnerables. Proveedores de hosting y entidades públicas costarricenses que operan volúmenes XFS con reflink habilitado siguen, 24 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 -la misma advertencia que esta sección repite desde el 30 de julio.