La IA de Microsoft detecta fallos de memoria en Rust, uno oculto desde 2015

Un análisis de Microsoft asistido por inteligencia artificial ha detectado varios fallos de seguridad relacionados con la memoria en la biblioteca estándar de Rust. Según el equipo investigador, uno de ellos estaba en la gestión de señales de process::exit desde 2015: un hilo secundario podía eliminar por error la pila alternativa de señales del hilo principal mientras este seguía activo.

El hallazgo importa porque Rust se utiliza para construir software e infraestructuras, y porque su modelo de seguridad de memoria no elimina todos los riesgos en componentes que interactúan con el sistema operativo o contienen código unsafe. Microsoft indica que los mantenedores de Rust ya han corregido la mayor parte de los fallos identificados; el anuncio no detalla aquí qué versiones incluyen cada reparación.

Qué ocurría con la pila de señales

Las señales permiten al sistema operativo comunicar ciertos eventos a un proceso. En el caso descrito por Microsoft, la secuencia problemática comenzaba cuando un hilo secundario ejecutaba la función de salida. Según el análisis, esa operación eliminaba por error la pila alternativa de señales asociada al hilo principal, aunque este no hubiera dejado de funcionar.

La consecuencia se manifestaría si, más adelante, el hilo principal sufría un desbordamiento de pila. La pila alternativa sirve para que el sistema pueda gestionar esa señal incluso cuando la pila normal está agotada. Sin ella, el sistema operativo no podría tramitar correctamente la alerta y la aplicación podría terminar de forma abrupta. Es, por tanto, un fallo en una condición concreta de interacción entre hilos y manejo de señales; la descripción publicada no permite concluir que cualquier programa escrito en Rust estuviera expuesto de la misma manera.

Otros patrones detectados en la biblioteca

El equipo de FORGE Lab de Microsoft también describió problemas que agrupó en tres patrones. El primero está relacionado con los pánicos: una interrupción del programa durante una operación puede impedir una limpieza prevista y dejar estructuras de memoria en un estado incorrecto. Como ejemplo, señaló MapWindows::clone, donde, según el análisis, durante una copia el proceso de limpieza podía intentar destruir memoria que no se había inicializado.

Un segundo patrón afecta a la confianza en implementaciones aportadas por quien programa. La biblioteca puede depender de que una función personalizada cumpla determinadas condiciones. Microsoft informó de un caso en str::replace: una regla personalizada podía introducir bytes no válidos y corromper una cadena que debía conservar el formato UTF-8. El ejemplo muestra por qué una interfaz que acepta comportamiento definido por el usuario necesita mantener y comprobar sus invariantes, no limitarse a asumir que cualquier implementación los respeta.

El tercer patrón se refiere a suposiciones sobre el estado del sistema operativo. En CommandExt::exec, Microsoft describió un escenario en el que modificar variables de entorno mientras se estaban leyendo podía provocar el acceso a memoria ya liberada. La relevancia de este tipo de fallo está en que el estado global puede cambiar durante la ejecución: el programa no siempre controla por sí solo todas las operaciones que concurren sobre esos datos.

Qué aporta la búsqueda con agentes de IA

Microsoft atribuye estos resultados a Hyenas, una versión de exploración basada en agentes de su sistema MDASH. La función que destaca el equipo es analizar cómo interactúan el software, la memoria y los procesos en tiempo real, en lugar de limitar la búsqueda a localizar patrones de código aislados. La IA intervino en la investigación, pero los hallazgos descritos son problemas concretos que requieren análisis técnico y corrección por parte de quienes mantienen el código.

La noticia no demuestra que una herramienta automática sustituya la revisión humana ni que encuentre todos los fallos de una biblioteca. Sí ilustra un uso defensivo de los agentes: explorar interacciones complejas y señalar condiciones que pueden pasar inadvertidas en una revisión convencional. Para que ese hallazgo mejore la seguridad, después hay que reproducir y entender el problema, determinar el alcance, preparar una solución y comprobar que no introduce regresiones.

Qué deberían revisar los equipos que usan Rust

Para responsables de desarrollo y de sistemas, la consecuencia práctica es seguir las correcciones publicadas por los mantenedores y comprobar qué versión de Rust y qué dependencias utilizan sus proyectos. La ficha del anuncio indica que la mayor parte de los fallos ya se ha corregido, pero no identifica versiones ni establece que todas las correcciones estén disponibles en cualquier distribución. Por eso, no basta con asumir que actualizar el compilador resuelve automáticamente cada caso: también importa cómo se incorporan las versiones de la biblioteca y las dependencias en cada entorno.

El caso tampoco invalida las garantías de Rust. Su diseño ayuda a prevenir muchas clases de errores de memoria, pero las bibliotecas estándar deben interactuar con el sistema operativo, gestionar concurrencia y, en determinados puntos, apoyarse en código que requiere garantías adicionales. La seguridad depende de que esas fronteras mantengan sus invariantes y de que los errores que se descubren se corrijan y lleguen a los proyectos que los necesitan.

El artículo original de Computer Hoy recoge los detalles atribuidos a la investigación de Microsoft.