SCTPhantom, una falla de 18 años en SCTP documentada por Tencent Zhuque Lab, permite escalar a root en Debian, Ubuntu, Rocky Linux, RHEL y OpenCloudOS aunque el kernel ya la corrigió el 3 de agosto; Arch Linux suspende la adopción de paquetes en el AUR tras una ola que comprometió al menos 89 paquetes; Debian debate cinco propuestas sobre código generado con IA sin fecha de votación; el kernel Linux 7.2-rc6 restaura una protección contra pérdida de datos en Btrfs; y RefluXFS cumple 23 días sin parche en cuatro versiones activas de Ubuntu.
El equipo de investigación Zhuque Lab, de Tencent, divulgó públicamente el 6 de agosto de 2026 una falla de 18 años en el subsistema SCTP (Stream Control Transmission Protocol) del kernel Linux, identificada como CVE-2026-64564 y nombrada SCTPhantom, según reportó The Hacker News. Los investigadores demostraron una escalada de privilegios completa hasta root en instalaciones por defecto de Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 y OpenCloudOS, a partir de una condición de carrera presente en el manejo de sockets SCTP desde 2008. El kernel oficial ya había corregido la falla, sin publicidad previa, en las versiones estables 7.1.6, 6.18.42, 6.12.101 y 6.6.148, publicadas el 3 de agosto -tres días antes de que Tencent hiciera pública la vulnerabilidad. La falla lleva casi dos décadas presente en un componente que muchas distribuciones no habilitan para uso general: SCTP es un protocolo de transporte poco común fuera de redes de telecomunicaciones y sistemas de señalización, lo que exige que el atacante tenga acceso local a una máquina donde el módulo esté cargado y alcanzable, según precisó la misma cobertura de The Hacker News. Esa condición reduce la exposición real frente a una falla de root explotable de forma remota, aunque no la elimina: entornos que cargan el módulo SCTP por defecto -algunas configuraciones de contenedores y sistemas de telecomunicaciones- quedan expuestos hasta que apliquen los kernels ya corregidos. La información de esta nota proviene de una sola cobertura, sin confirmación cruzada de un segundo medio independiente al cierre de esta edición. Tencent Zhuque Lab no publicó, al cierre de esta edición, una prueba de concepto pública ni un cronograma para que las distribuciones derivadas incorporen los kernels ya corregidos en sus repositorios estables. La misma versión 7.1.6 del kernel Linux que cerró esta falla fue la que esta sección cubrió el 6 de agosto por sus más de 150 parches de seguridad; instituciones y empresas costarricenses que corren Debian, Ubuntu o Rocky Linux en servidores de telecomunicaciones o de señalización deben verificar si tienen el módulo SCTP cargado mientras esperan que sus distribuciones distribuyan el parche.
Arch Linux desactivó la adopción de paquetes huérfanos en el AUR después de que atacantes secuestraran al menos 89 paquetes con malware que roba credenciales y se propaga por SSH.
El equipo de DevOps de Arch Linux, encabezado por Robin Candau, desactivó el 30 de julio de 2026 la función que permite adoptar paquetes huérfanos en el AUR (Arch User Repository), el repositorio comunitario donde cualquier usuario puede publicar y mantener paquetes, después de que atacantes tomaran el control de al menos 89 paquetes -entre ellos openconnect-sso- para inyectar un malware de dos etapas basado en la red Tor, según documentaron BleepingComputer y la firma de investigación Corgea. El malware roba tokens y credenciales guardadas, se propaga a través de conexiones SSH activas y mantiene persistencia en el sistema comprometido, de acuerdo con la misma cobertura. El episodio es el tercer incidente de cadena de suministro que golpea al AUR desde junio, según Corgea, que vincula la carga útil de esta ola con la de una campaña anterior conocida como Atomic Arch. El patrón repite lo que ocurrió apenas dos días antes en el ecosistema de paquetes de Node.js, donde el gusano CHAINDROP comprometió más de 440 paquetes con más de 2.000 millones de descargas mensuales combinadas tras robar la cuenta de un mantenedor, según Microsoft Security. La coincidencia entre ambos casos expone la misma debilidad estructural: repositorios de código abierto que dependen de mantenedores individuales y de mecanismos de adopción o transferencia de paquetes sin verificación reforzada de identidad son, según ambos casos documentados esta semana, un blanco recurrente para atacantes que buscan escalar un solo compromiso en cientos de instalaciones. Suspender la adopción de paquetes resuelve el vector inmediato, pero no corrige el problema de fondo: el modelo de mantenimiento voluntario del AUR, que la propia documentación de Arch Linux describe como software para "usar bajo su propio riesgo", sigue sin un mecanismo de verificación previa al primer uso. Arch Linux no fijó, al cierre de esta edición, una fecha para reactivar las adopciones ni confirmó cuántos usuarios instalaron alguno de los 89 paquetes comprometidos. Costa Rica no tiene cifras propias de adopción de Arch Linux, pero la comunidad tica de usuarios avanzados y desarrolladores que mantiene paquetes propios en el AUR -activa en foros y grupos locales de Linux- es la que debe revisar manualmente si instaló alguno de los paquetes señalados mientras el repositorio permanece sin ese mecanismo de adopción.
El proyecto Debian mantiene abierta desde el 24 de julio de 2026 una discusión formal sobre cinco propuestas de resolución general que definirían cómo la distribución trata las contribuciones asistidas por modelos de lenguaje, según reportaron LinuxCompatible y el medio alemán Heise. La propuesta A, impulsada por el desarrollador Matthias Geiger, plantea una prohibición completa del código, los recursos web y las comunicaciones oficiales generados con IA dentro del proyecto; las otras cuatro opciones ofrecen distintos grados de permisividad, todas con la exigencia común de que el contribuyente declare el uso de la herramienta y acepte responsabilidad por el resultado, de acuerdo con la misma cobertura. La votación todavía no tiene fecha de cierre confirmada, la misma situación que esta sección documentó el 6 y el 7 de agosto al cubrir la nueva política de Rust, que sí entró en vigor de forma acotada mientras Debian continúa en fase de debate. El alcance de la resolución de Debian, según precisó LinuxCompatible, se limita al trabajo propio del proyecto -empaquetado, documentación e infraestructura- y no regula el código de los proyectos que empaqueta ni el uso de IA en el desarrollo original de esos programas. La tensión de fondo, según Heise, enfrenta el temor a la fatiga de revisores voluntarios y a la falta de claridad sobre derechos de autor del código generado por IA contra la realidad de que buena parte de los mantenedores ya usa estas herramientas en su trabajo diario. Debian no confirmó, al cierre de esta edición, cuándo abrirá formalmente el período de votación entre las cinco propuestas. Costa Rica no tiene desarrolladores identificados entre los promotores de las cinco resoluciones, pero la comunidad tica que empaqueta o mantiene software para Debian y sus derivadas -Ubuntu incluida- deberá ajustarse a la regla que finalmente se apruebe la próxima vez que envíe una contribución asistida por IA.
cat /feed/kerneldesarrollo.md
Linus Torvalds publicó el 2 de agosto la sexta candidata de Linux 7.2, inusualmente grande, mientras Btrfs recupera un mecanismo de protección contra pérdida de datos retirado por error.
> > git tag -l 'v7.2-rc*' --sort=-creatordate | head -1
> > v7.2-rc6 | fecha: 2026-08-02 | autor: Linus Torvalds
> Linus Torvalds publicó el 2 de agosto de 2026 la sexta candidata de la serie de desarrollo Linux 7.2, según el repositorio público del kernel en GitHub. Phoronix describió esta candidata como "huge" ("enorme") en volumen de cambios para una fase tan avanzada del ciclo, de acuerdo con su cobertura del lanzamiento. Entre los cambios de esta semana, el sitio especializado Kernel & Embedded News reportó que el sistema de archivos Btrfs restauró el mecanismo de "COW fixup", encargado de detectar páginas sucias sin una extensión ordenada asociada, después de que su eliminación durante la ventana de fusión de 7.2 -bajo el supuesto de que la capa de gestión de memoria ya cubría ese caso- terminara provocando pérdida silenciosa de datos en la práctica.
> > por qué importa: un fallo de esta naturaleza en Btrfs -sistema de archivos copy-on-write usado por defecto en openSUSE y disponible como opción en Fedora, Ubuntu y otras distribuciones- no genera un error visible para el usuario; los datos simplemente se pierden sin aviso, lo que vuelve crítico detectarlo antes de que la versión estable llegue a producción. El propio ciclo de candidatas -para eso sirven las siete u ocho rc de cada serie- permitió identificar y revertir el problema antes del lanzamiento final.
> > qué sigue: el kernel Linux 7.2 estable se espera entre el 16 y el 23 de agosto de 2026, según estimaciones de la cobertura especializada, con al menos una candidata más (rc7) prevista este fin de semana. Costa Rica no participa del desarrollo del kernel, pero las universidades públicas y las empresas ticas que corren openSUSE o usan Btrfs en servidores propios reciben esta corrección de forma indirecta en cuanto sus distribuciones adopten la versión 7.2 estable.
El Pisuika confirmó este 8 de agosto que el rastreador de Canonical no registra cambios desde el 6 de agosto: solo Ubuntu 26.04 figura en trabajo en curso.
El Pisuika confirmó, al consultar directamente ubuntu.com el 8 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" ("trabajo en curso"), mientras las cuatro versiones LTS con soporte activo y afectadas -24.04, 22.04, 20.04 y 18.04- permanecen como "vulnerable", sin fecha de parche. La prioridad de la falla se mantiene en "Medium" según la misma página, sin cambios desde el 23 de julio -16 días-, y Canonical no publicó ningún aviso de seguridad nuevo desde el USN-8620-4 del 31 de julio, según confirmó El Pisuika al revisar el listado oficial de avisos: son ocho días corridos sin un USN nuevo. El commit 2f4acd0, que corrigió la condición de carrera de RefluXFS en el kernel Linux oficial, cumple 23 días fusionado en el árbol del kernel desde el 16 de julio. Que el único movimiento visible en tres semanas sea el cambio de estado de la versión más reciente -26.04, la LTS con menos instalaciones activas del parque de Ubuntu- repite la misma pregunta sin respuesta que esta sección planteó el 7 de agosto: si Canonical prioriza el parche por antigüedad de la versión, por facilidad técnica de retroportarlo, o por otro criterio que la compañía no ha explicado. Las versiones con más años de despliegue en producción -22.04 y 20.04- siguen exactamente donde estaban hace ocho días. 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, 23 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.