PinTheft: cómo un fallo en RDS permite escalar privilegios a root en Linux

Qué componente del kernel afecta PinTheft

El fallo reside en el subsistema RDS (Reliable Datagram Sockets) del kernel de Linux. RDS es un protocolo de red usado principalmente en entornos de alto rendimiento, como clusters que utilizan InfiniBand o ciertas plataformas distribuidas.

El problema aparece en la ruta de envío zerocopy de RDS, una optimización que permite enviar datos directamente desde la memoria de usuario sin copias intermedias. Aunque mejora el rendimiento, también introduce una lógica de gestión de memoria compleja.

En particular, la función rds_message_zcopy_from_user() fija ("pin") páginas de memoria de usuario una por una para preparar la transmisión. Si durante el proceso ocurre un page fault, el código de manejo de errores intenta liberar las páginas previamente fijadas, pero bajo ciertas condiciones lo hace incorrectamente, provocando una doble liberación (double‑free) o un contador de referencias corrupto.

Ese estado inconsistente de memoria es la base que permite construir el exploit.

Cómo funciona el exploit PinTheft (explicación simplificada)

Los investigadores demostraron que el fallo puede combinarse con otras funciones modernas del kernel para convertir un error de memoria en una técnica fiable de escalada de privilegios.

1. Activación del bug en RDS

Un usuario local provoca la ruta vulnerable del envío zerocopy en RDS. Cuando ocurre un fallo de página durante el proceso de fijado de páginas, la rutina de limpieza libera memoria que aún debería estar referenciada por el kernel. Esto deja páginas en un estado inconsistente o reutilizables prematuramente.

2. Reutilización de páginas con io_uring

El siguiente paso utiliza io_uring, la interfaz moderna de I/O asíncrono de Linux. En particular, el exploit emplea buffers fijos registrados en io_uring.

Manipulando estos buffers, el atacante puede reclamar las páginas físicas que fueron liberadas erróneamente, logrando controlar qué datos terminan en esas ubicaciones de memoria.

3. Convertir la corrupción en sobrescritura de page cache

Las páginas reutilizadas pueden pertenecer a la page cache, el mecanismo del kernel que mantiene en memoria el contenido de archivos para acelerar su acceso.

Si el atacante logra escribir datos en esas páginas, puede alterar lo que el kernel devuelve cuando un proceso lee un archivo, sin modificar el archivo real en disco.

4. Manipulación de un binario SUID‑root

La cadena de explotación se dirige a la copia en caché de un ejecutable con el bit SUID activado (SUID‑root). Estos programas se ejecutan con privilegios de root incluso si los lanza un usuario normal.

Al alterar la versión del binario que reside en la page cache, el kernel termina ejecutando código modificado por el atacante pero con privilegios de root, lo que concede acceso completo al sistema.

Qué sistemas pueden verse más afectados

La presencia del bug depende del kernel instalado y de la configuración del sistema.

Arch Linux

Varios informes de seguridad señalan que Arch Linux fue uno de los entornos donde primero se demostró el exploit funcional:

• El PoC público se probó con éxito en sistemas Arch.
• El módulo RDS puede estar disponible dependiendo de la configuración del kernel.

Esto convirtió a Arch en uno de los principales objetivos durante las pruebas iniciales del exploit.

Sistemas con el módulo RDS disponible

En teoría, cualquier distribución Linux podría verse afectada si:

• Ejecuta un kernel vulnerable.
• El módulo RDS está cargado o puede cargarse.

Muchos sistemas empresariales no utilizan RDS en absoluto, lo que reduce la superficie de ataque.

Configuraciones empresariales estándar

Instalaciones por defecto de Ubuntu, Debian, RHEL o AlmaLinux suelen tener menor exposición porque el módulo RDS generalmente no está habilitado o cargado por defecto. Aun así, los administradores deberían verificar la configuración real del kernel en lugar de asumirlo.

Plataformas CloudLinux

CloudLinux indicó que probó el exploit público en varias versiones de su plataforma y concluyó que sus sistemas no se ven afectados según sus pruebas internas.

Condiciones necesarias para explotar la vulnerabilidad

Para que el ataque funcione normalmente deben cumplirse varios requisitos:

• El atacante necesita ejecución de código local como usuario sin privilegios.
• El sistema debe usar un kernel vulnerable con el bug de RDS zerocopy.
• El módulo RDS debe estar disponible o cargado.
• io_uring debe estar permitido para usuarios no privilegiados, ya que el exploit usa buffers fijos de esta API.
• Debe existir un binario SUID‑root que pueda ser objetivo de la sobrescritura de la page cache.

Si alguno de estos factores no se cumple, el exploit se vuelve mucho más difícil o directamente inviable.

Medidas de mitigación y recomendaciones

Instalar las actualizaciones del kernel

Los mantenedores del kernel ya publicaron parches que corrigen la ruta vulnerable en RDS. Instalar el kernel actualizado proporcionado por la distribución es la medida principal de protección.

Después de actualizar, es necesario reiniciar el sistema para que el nuevo kernel entre en funcionamiento.

Deshabilitar el módulo RDS si no se utiliza

Si tu infraestructura no usa RDS, puedes reducir el riesgo evitando que el módulo se cargue.

Medidas habituales incluyen:

• Añadir rds a la lista de módulos bloqueados (blacklist)
• Eliminarlo de configuraciones de carga automática

Limitar el uso de io_uring por usuarios no privilegiados

Dado que el exploit depende de io_uring fixed buffers, restringir o desactivar su uso para usuarios sin privilegios puede reducir la superficie de ataque en algunos entornos.

Auditar binarios SUID

La etapa final del ataque depende de ejecutables SUID‑root. Revisar qué programas tienen el bit SUID y eliminarlo cuando no sea necesario reduce posibles objetivos.

Reducir el acceso local en sistemas compartidos

Como PinTheft requiere ejecución local, los sistemas con múltiples usuarios —como servidores compartidos, runners de CI/CD o máquinas de desarrollo— deberían priorizar la actualización y el endurecimiento de seguridad.

La lección de seguridad detrás de PinTheft

PinTheft muestra cómo muchos exploits modernos del kernel se basan en encadenar varios subsistemas avanzados. En este caso, un bug de memoria en RDS se combina con las capacidades de alto rendimiento de io_uring para convertir un error aparentemente menor en una escalada completa a root.

También recuerda que módulos del kernel poco utilizados pueden convertirse en superficies de ataque críticas cuando interactúan con nuevas optimizaciones del sistema. Mantener el kernel actualizado y desactivar módulos innecesarios sigue siendo una de las defensas más efectivas frente a este tipo de vulnerabilidades.