La primera CVE de Rust en el kernel Linux y la lección que deja ( CVE-2025-68260)

CVE-2025-68260 es la primera vulnerabilidad atribuida a código Rust en el kernel Linux, en el subsistema rust_binder. No se trata de un error clásico de memoria, sino de una condición de carrera originada por una suposición incorrecta en un bloque unsafe, válida en ejecución secuencial pero incorrecta bajo concurrencia. El caso marca un hito en la adopción de Rust en sistemas críticos y evidencia con claridad sus límites reales.

La asignación de CVE-2025-68260 marca un punto relevante en la historia reciente del kernel Linux. No porque exponga una debilidad estructural de Rust, sino porque es la primera vulnerabilidad atribuida explícitamente a código Rust dentro del kernel, en este caso en el subsistema rust_binder. Y precisamente por cómo ocurre, es una lección mucho más interesante de lo que aparenta.

No se trata de un buffer overflow clásico ni de un use-after-free, errores históricamente dominantes en código C. El problema fue más sutil y, por lo mismo, más revelador: una condición de carrera causada por un invariante incorrectamente definido dentro de un bloque unsafe. Rust no falló como lenguaje. Falló una suposición humana.

El origen del problema estuvo en un comentario de SAFETY que asumía que un nodo del binder estaba “o en la lista o en ninguna lista”. Esa afirmación era válida en un modelo secuencial, pero falsa en un entorno concurrente. En la práctica, un hilo movía elementos desde death_list a una lista temporal después de liberar el lock, mientras otro hilo podía modificar la lista original en paralelo. El resultado fue corrupción de punteros de lista y un kernel crash, exactamente el tipo de fallo que Rust busca reducir, pero que unsafe permite cuando el modelo mental es incorrecto.

La corrección fue tan simple como contundente: procesar los elementos directamente desde la lista original mientras el lock permanece retenido. No se añadió complejidad, no se introdujo lógica nueva. Se eliminó una suposición inválida. Eso, por sí solo, dice mucho sobre la naturaleza del error.

La lección central es clara. unsafe no es “gratis”, ni siquiera en Rust, y menos aún en código concurrente de kernel. Rust protege de forma efectiva contra la mayoría de los errores estructurales, pero el pequeño porcentaje que queda fuera del alcance del compilador se vuelve más crítico precisamente porque todo lo demás es seguro. Un invariante mal documentado dentro de unsafe no es un detalle menor, es deuda técnica de alto riesgo.

El contexto temporal refuerza esta lectura. El mismo día que se asignó esta CVE en Rust, se publicaron múltiples vulnerabilidades asociadas al código C del kernel. Esto pone en perspectiva una verdad que a veces se pierde entre discursos simplistas: Rust no elimina los bugs, cambia su distribución. Reduce drásticamente clases enteras de errores —memoria, lifetimes, aliasing— pero concentra el riesgo restante en zonas muy específicas: unsafe, concurrencia y lógica de invariantes. Hay menos errores, pero son más “afilados”.

Esto lleva a una pregunta más profunda y necesaria: cómo documentar y auditar invariantes en unsafe, especialmente bajo concurrencia. La práctica que está emergiendo como más sana es tratar estos invariantes casi como contratos formales. No basta con un “this is safe because…”. Ese comentario debe dejar explícito qué hilos existen, qué locks protegen qué estados y qué condiciones no pueden cambiar mientras el invariante se asume verdadero. Si eso no puede expresarse claramente en lenguaje natural, probablemente el unsafe está mal encapsulado.

En cuanto a herramientas, no hay soluciones mágicas. Miri ayuda a detectar comportamiento indefinido y violaciones de aliasing, pero no modela concurrencia real. Loom es extremadamente valioso para forzar interleavings complejos, aunque su costo cognitivo es alto. Los sanitizers siguen siendo útiles incluso en entornos cercanos al kernel. Y, por sobre todo, el code review especializado en unsafe, tratado como un artefacto crítico y no como código ordinario, sigue siendo insustituible.

Lejos de ser una mala noticia, CVE-2025-68260 es una buena señal de madurez. Muestra que los errores se identifican, se clasifican y se corrigen con transparencia. Y deja claro que el debate relevante ya no es “Rust versus C”, sino algo mucho más interesante y difícil: cómo diseñar invariantes correctos en sistemas concurrentes donde ni siquiera Rust puede salvarte de una suposición equivocada.

Equipo vCISO

https://vciso.cloud