CVE-2026-43494 / PinTheft: riesgo de elevacion local por la combinacion de Linux RDS e io

CVE-2026-43494 es un riesgo de elevacion local de privilegios en el kernel Linux. La cadena de explotacion relacionada tambien se conoce publicamente como PinTheft. La clave no es una entrada remota, sino si un usuario local con pocos privilegios puede reunir al mismo tiempo RDS zerocopy, io_uring fixed buffers, un programa SUID-root legible y una version de kernel adecuada.

Conviene aclarar primero un detalle de nomenclatura: el directorio del repositorio Unclecheng-li/poc-lab se llama CVE-2026-43494 PinTheft, mientras que el titulo del README tambien menciona QVD-2026-27616 - PinTheft. Segun las entradas CVE publicas y avisos de terceros, CVE-2026-43494 apunta a un problema de Linux kernel RDS zerocopy en el que op_nents no se reinicia correctamente, lo que provoca una anomalia de double-free / conteo de referencias. QVD-2026-27616 parece mas bien un identificador de aviso de riesgo de Qianxin. En una investigacion real, registre ambos identificadores, pero tome como referencia principal los avisos de seguridad de la distribucion y el estado de los parches del kernel.

Cual Es el Nucleo de la Vulnerabilidad

El problema aparece en la ruta de envio zerocopy de Linux RDS, Reliable Datagram Sockets. Las descripciones publicas senalan estas funciones clave:

1
2


rds_message_zcopy_from_user()
rds_message_purge()

Cuando iov_iter_get_pages2() falla dentro de rds_message_zcopy_from_user(), las paginas que ya fueron fijadas pueden liberarse por la ruta de error, pero el estado relacionado con op_nents no se limpia correctamente. Mas tarde, rds_message_purge() todavia puede liberar otra vez las entradas residuales. El resultado es que las referencias de un mismo grupo de paginas se decrementan demasiadas veces, creando un error de conteo de referencias explotable.

Visto por separado, el bug de RDS es un problema de gestion de memoria en una ruta de error del kernel. PinTheft es peligroso porque la cadena de explotacion lo conecta con el mecanismo de buffers fijos de io_uring: io_uring conserva un struct page * antiguo, mientras que la pagina ya fue liberada y reasignada para otro uso. El PoC publico lleva ese estado hacia la sobrescritura del page cache de un programa SUID-root y finalmente alcanza elevacion local de privilegios.

Por Que Se Llama PinTheft

io_uring REGISTER_BUFFERS fija paginas de usuario. Para paginas normales, FOLL_PIN no es solo un incremento simple de una referencia; aumenta el page refcount mediante un bias mayor. El PoC publico usa el concepto GUP_PIN_COUNTING_BIAS = 1024.

El nombre PinTheft significa que la cadena de ataque “roba” repetidamente esas referencias pin a traves de la ruta de fallo de RDS zerocopy. Cuando las referencias se agotan, io_uring sigue creyendo que mantiene una pagina valida, pero esa pagina fisica ya puede liberarse y reutilizarse por el page cache.

Este tipo de vulnerabilidad se malinterpreta facilmente como “modificar directamente /usr/bin/su en disco”. Una descripcion mas precisa es que la cadena intenta sobrescribir el page cache en memoria. El archivo en si no necesariamente se escribe de vuelta al disco, pero cuando el kernel ejecuta ese programa SUID, puede leer instrucciones desde la cache de pagina contaminada y ejecutar la carga del atacante.

Las Condiciones de Activacion No Son Amplias

No es una vulnerabilidad del tipo “cualquier servidor Linux puede ser atacado remotamente”. La informacion publica indica que la cadena de explotacion depende al menos de estas condiciones:

El kernel tiene habilitados CONFIG_RDS y CONFIG_RDS_TCP.
El sistema tiene habilitado CONFIG_IO_URING, y kernel.io_uring_disabled=0.
Los modulos rds / rds_tcp ya estan cargados, o un usuario de bajos privilegios puede activar la carga automatica.
Existe localmente un binario SUID-root legible, como /usr/bin/su, /usr/bin/passwd o /usr/bin/pkexec.
El PoC publico tambien depende de la API mas reciente IORING_REGISTER_CLONE_BUFFERS. El analisis de CloudLinux indica que el PoC publico encaja mejor con kernel 6.13 o posterior.

Si falta cualquiera de estos enlaces, la ruta publica de explotacion se rompe. Por ejemplo, muchas distribuciones de la familia RHEL no compilan RDS por defecto, kernels antiguos de Ubuntu pueden no tener la API de clone buffer de io_uring que necesita el PoC, y algunos entornos restringen la carga automatica de modulos RDS por usuarios sin privilegios.

Autocomprobacion en Un Minuto

Primero, revise la configuracion del kernel:

1
2


zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

Luego revise si io_uring esta deshabilitado:

1

cat /proc/sys/kernel/io_uring_disabled 2>/dev/null

Los valores comunes pueden interpretarse asi:

0: permitido, con la mayor superficie de riesgo.
1: restringido para usuarios sin privilegios; el comportamiento exacto depende de la version del kernel y la politica de la distribucion.
2: io_uring deshabilitado.

Revise si los modulos RDS existen y pueden cargarse:

1
2


lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

Si CONFIG_RDS esta en not set, o el sistema no tiene ningun modulo rds_tcp, normalmente no se puede llegar a este bug. En cambio, si RDS esta disponible, io_uring no esta deshabilitado y el sistema usa un kernel general relativamente nuevo, conviene elevar la prioridad y seguir comprobando el estado de correccion de la distribucion.

Que Maquinas Merecen Prioridad

Priorice estos entornos:

Hosts Linux multiusuario, maquinas de ensenanza, bastiones y maquinas de desarrollo compartidas.
Hosts de contenedores, especialmente entornos que permiten usuarios locales no confiables o tienen una superficie de escape de contenedores mas laxa.
Escritorios o servidores con kernels mainline / rolling recientes, por ejemplo distribuciones rolling tipo Arch.
HPC, Oracle RAC u otros escenarios que puedan usar RDS de forma real.
CI workers, maquinas de compilacion y entornos de laboratorio que permiten a usuarios sin privilegios ejecutar mucho codigo local.

En un servidor web comun donde solo cuentas de servicio controladas ejecutan aplicaciones y RDS no esta habilitado, el riesgo practico baja mucho. Pero “mucho mas bajo” no significa “ignorar”: el impacto tipico de una elevacion local en kernel es que el atacante primero obtiene bajos privilegios mediante Web, SSH, CI, contenedores o una vulnerabilidad de aplicacion, y luego usa el bug local para ampliar su control.

Medidas Temporales de Mitigacion

La solucion formal debe seguir viniendo de la actualizacion del kernel de la distribucion. El estado de parches, versiones con backport y rangos afectados debe revisarse en los avisos de Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, Arch, proveedores cloud o imagenes base de contenedores. No juzgue solo por el numero de version upstream.

Mientras espera parches, o si no puede reiniciar el kernel de inmediato, puede elegir medidas temporales segun el entorno:

1
2
3
4
5


# Si el negocio no depende de RDS, bloquee la carga de los modulos relacionados
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

Si el negocio no depende de io_uring, tambien puede considerar deshabilitarlo o restringirlo:

1

sudo sysctl -w kernel.io_uring_disabled=2

La configuracion persistente debe escribirse en el archivo correspondiente bajo /etc/sysctl.d/*.conf. Tenga cuidado con este paso: bases de datos modernas, proxies, runtimes o programas de I/O de alto rendimiento pueden usar io_uring. Antes de cambiar produccion, confirme las dependencias del negocio.

Como Verificar Despues de Corregir

Tras actualizar el kernel, no se limite a mirar que el gestor de paquetes haya terminado con exito. Conviene confirmar tres cosas:

1
2
3


uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

Si el aviso de la distribucion dice claramente que CVE-2026-43494 esta corregido, el kernel puede estar protegido aunque uname -r no parezca la version upstream mas reciente, porque el kernel estable de la distribucion puede haber recibido un parche con backport. En cambio, si el kernel proviene de una compilacion propia, un repositorio de terceros, una imagen de marketplace cloud o una plantilla de host de contenedores, siga verificando el commit del parche y la fecha de build.

CVE-2026-43494 / PinTheft: riesgo de elevacion local por la combinacion de Linux RDS e io_uring