La nueva vulnerabilidad del núcleo CVE-2026-43494, denominada «PinTheft», permite obtener privilegios de root locales cuando RDS e io_uring están expuestos

La versión resumida

Qué: Una nueva vulnerabilidad de escalada de privilegios locales en Linux denominada PinTheft. Aprovecha un fallo de recuento de referencias en la ruta de envío «zerocopy» del RDS (Reliable Datagram Sockets) del núcleo, junto con io_uring, para sobrescribir un binario SUID con privilegios de root en memoria. El resultado es un shell con privilegios de root desde una cuenta local sin privilegios. A la fecha de publicación, aún no se le ha asignado ningún CVE.

Repercusión: Una demostración pública de viabilidad realizada por V12 Security permite a cualquier usuario local sin privilegios obtener acceso de root de forma fiable en los equipos afectados. El fallo subyacente ha estado presente en el núcleo de Linux desde la versión 4.17, lanzada en 2018.

Situación: Aaron Esau, de V12 Security, la empresa a la que se atribuye el descubrimiento, reveló PinTheft en mayo, con un parche para el kernel ya disponible. El corrección candidata del desarrollador original se publicó en la lista de correo del kernel de netdev el 5 de mayo de 2026. Se le asignó el CVE-2026-43494, sin puntuación CVSS. Consulte la sección «Parche sin reinicio de KernelCare» más abajo para conocer el estado actual.

Gravedad: Vektor local ; requiere la capacidad de ejecutar código en el host como cualquier usuario local; no requiere interacción del usuario. Para que la vulnerabilidad sea explotable en la práctica, deben darse todas las condiciones siguientes en el sistema de destino: RDS y RDS_TCP deben estar disponibles y poder cargarse, io_uring debe estar habilitado, debe existir un binario SUID-root legible y debe disponerse de una carga útil x86_64 (el PoC es específico de la arquitectura, aunque la técnica no lo sea). V12 afirmó que, entre las distribuciones comunes que probaron, RDS solo se podía cargar de forma predeterminada en Arch Linux. Otras distribuciones incluyen el módulo bloqueado para que no se cargue automáticamente o no lo compilan en absoluto.

Por qué es importante: La cadena de exploits es fiable, la prueba de concepto es pública y aún no hay ningún CVE ni aviso oficial del proveedor. Los sistemas Linux multitenant (alojamiento compartido, entornos de integración continua, hosts de contenedores) que utilicen las distribuciones afectadas deben considerarse en riesgo inmediato.

Haz lo siguiente ahora mismo: si tu servidor no ejecuta ninguna carga de trabajo RDS —y la mayoría no lo hace—, bloquea los módulos rds y rds_tcp mediante una regla modprobe. Si no necesitas io_uring y tu kernel es la versión 6.6 o posterior, también puedes desactivarlo con un comando sysctl. A continuación se indican los comandos de mitigación y la solución alternativa para kernels más antiguos.

La versión larga

V12 Security publicó la prueba de concepto de PinTheft y un informe técnico en mayo de 2026. El descubrimiento se atribuye a Aaron Esau. La vulnerabilidad en sí misma ha estado presente en el núcleo de Linux desde la versión 4.17 de 2018, pero la cadena de explotación depende de las funciones de io_uring, que aún no existían cuando se introdujo el error.

La corrección del núcleo candidata se publicó en la lista de correo de netdev el 5 de mayo de 2026. Los núcleos de las distribuciones derivadas aún la están incorporando. El equipo de ingeniería de KernelCare está preparando parches que no requieren reinicio para los núcleos compatibles afectados.

En algunas de las primeras noticias se relacionaba PinTheft específicamente con el núcleo 6.13 y versiones posteriores. Esto se debe a las dependencias del PoC publicado, no a la antigüedad del fallo subyacente: el problema del contador de referencias en la ruta zerocopy de RDS es mucho más antiguo, pero una cadena de explotación funcional que reproduzca el PoC sigue requiriendo funciones recientes de io_uring.

Cómo funciona la vulnerabilidad

Cuando un programa envía datos a través de un socket de red, el núcleo suele copiar esos datos desde la memoria del programa a los búferes del núcleo. Para ahorrar ciclos de CPU, los núcleos modernos también ofrecen el envío «zerocopy»: el núcleo bloquea las páginas de memoria del usuario y las utiliza directamente. RDS, un protocolo menos habitual destinado a redes de centros de datos de alto rendimiento, es compatible con este modo «zerocopy».

El error radica en la forma en que RDS realiza la limpieza cuando falla un envío «zerocopy» a mitad del proceso. El núcleo acaba liberando las mismas páginas dos veces en lugar de una sola. Cada envío fallido resta una referencia de la primera página de usuario.

Por sí solo, se trata simplemente de un pequeño error de contabilidad. PinTheft lo convierte en un exploit de root a través de io_uring, la moderna interfaz de E/S asíncrona de Linux. io_uring permite a un programa registrar una página de memoria como un búfer fijo, lo que añade 1.024 referencias a dicha página. A continuación, el atacante fuerza 1.024 envíos RDS zerocopy fallidos para agotar silenciosamente todas esas referencias. El kernel cree ahora que nadie está utilizando la página y la libera, pero io_uring sigue manteniendo un puntero a ella.

A continuación, el atacante lee cualquier binario SUID con privilegios de root. El núcleo carga ese binario en la misma página liberada de su caché de páginas. Una sola operación de escritura io_uring en el búfer obsoleto sobrescribe el binario en memoria con código de shell. Al ejecutar el binario SUID, el usuario obtiene acceso a un shell con privilegios de root.

El archivo en el disco no se modifica. Lo que se sobrescribe es la copia de la caché de páginas que se encuentra en la memoria. Esto es importante para la limpieza, tal y como se explica en la sección de mitigación.

El fallo latente relacionado con el contador de referencias parece remontarse a la introducción de la compatibilidad con RDS zerocopy en Linux 4.x. Una explotación fiable, tal y como se muestra en la prueba de concepto, depende además de funciones más recientes de io_uring (en particular, IORING_REGISTER_CLONE_BUFFERS, disponible a partir de la versión 6.12), por lo que, aunque el fallo es antiguo, el margen para una explotación práctica es más reducido.

¿A quién afecta?

Lo único que importa es si el núcleo en ejecución puede cargar los módulos RDS, no el nombre de la distribución. Comprueba directamente la configuración del núcleo y la política de carga de módulos utilizando los comandos de la siguiente sección.

RDS que se puede cargar de forma predeterminada (confirmado por los investigadores): Arch Linux.

El módulo RDS se incluye, pero su carga automática está bloqueada de forma predeterminada: Ubuntu (todas las versiones actualmente compatibles, mediante un archivo de lista negra en el paquete kmod), Debian 11 y 12 (mediante un parche específico de Debian que desactiva la carga automática de RDS como medida de mitigación contra vulnerabilidades locales), Fedora (CONFIG_RDS=m, pero el módulo se incluye en kernel-modules-extra e incorpora su propio archivo de lista negra). En estos sistemas, la prueba de concepto (PoC) requiere que un administrador o una carga de trabajo cargue deliberadamente rds_tcp primero. Pruebas independientes también indican que cargar el módulo en un sistema estándar derivado de Debian no siempre es suficiente para que la PoC tenga éxito, por lo que el comportamiento varía.

Requiere verificación específica del proveedor o de la configuración: Amazon Linux 2023, openSUSE Tumbleweed, Proxmox VE 7/8/9, Oracle Linux UEK 6 y 7. Comprueba el archivo CONFIG_RDS en /boot/config-$(uname -r) y busca las reglas modprobe proporcionadas por el proveedor en /etc/modprobe.d/ y /lib/modprobe.d/.

No se ven afectados: RHEL, AlmaLinux, Rocky Linux y CentOS Stream 8/9/10 que ejecutan el núcleo compatible con Red Hat de serie; estas versiones no incluyen RDS. RHEL 9 y 10 también desactivan io_uring de forma predeterminada, lo que elimina la otra mitad de la cadena.

Hay una salvedad que prevalece sobre todo lo anterior: cualquier servidor que utilice un kernel personalizado o alternativo puede comportarse de forma diferente a su distribución de origen. En concreto, Oracle Linux UEK suele ejecutarse junto con el RHCK y se encuentra en una situación diferente.

Actúa ya

Hay dos soluciones prácticas. Elige en función de si tu proveedor utiliza RDS o io_uring.

Recomendado para la mayoría de los servidores: bloquear los módulos RDS

La gran mayoría de los servidores Linux no utilizan RDS. Se encuentra principalmente en Oracle Clusterware y en algunas configuraciones HPC con InfiniBand. En cualquier host que no ejecute una carga de trabajo RDS, la solución más sencilla es impedir que se carguen los módulos rds y rds_tcp.

sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp rds 2>/dev/null || true

El exploit sobrescribe el binario SUID únicamente en memoria. El archivo en el disco permanece inalterado. En cualquier host que haya podido verse afectado antes de la aplicación de las medidas de mitigación, vacíe la caché de páginas para eliminar cualquier modificación realizada en memoria:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Deshacer los cambios tras aplicar el parche del núcleo o el parche en vivo de KernelCare:

sudo rm /etc/modprobe.d/pintheft.conf

Si ejecutas cargas de trabajo RDS ( Oracle Clusterware, determinadas pilas HPC), no apliques esta medida correctiva. Utiliza la alternativa «io_uring» que se indica a continuación o espera a que esté disponible el núcleo parcheado.

Alternativa: desactivar io_uring en todo el sistema

El parámetro sysctl «kernel.io_uring_disabled» está disponible en Linux 6.6 y versiones posteriores. Los núcleos de las distribuciones anteriores a esa versión —incluidos Ubuntu 22.04 (5.15), Debian 11 (5.10) y 12 (6.1), Amazon Linux 2023 (6.1), RHEL 9 (5.14) y Ubuntu 24.04 (6.8 — comprueba tu versión específica)— no exponen este sysctl.

En esos núcleos, bloquear los módulos RDS es la opción más práctica. Desactivar io_uring por completo en los núcleos más antiguos requiere un parámetro de arranque o una recompilación del núcleo, y por lo general no merece la pena el esfuerzo en comparación con bloquear RDS.

Si tus cargas de trabajo no requieren io_uring, desactiva en su lugar la otra mitad de la cadena de explotación.

sudo sysctl -w kernel.io_uring_disabled=2

Esta es la configuración predeterminada en RHEL 10 y es la razón por la que esa familia de distribuciones queda fuera del ámbito de aplicación, independientemente del estado de RDS. Ten en cuenta que desactivar io_uring puede afectar a algunos motores de bases de datos modernos y a las cargas de trabajo de E/S asíncrona. Compruébalo en tu entorno antes de aplicarlo.

Persistir tras los reinicios:

echo 'kernel.io_uring_disabled = 2' | sudo tee /etc/sysctl.d/99-pintheft.conf
sudo sysctl --system

Defensa en profundidad en hosts reforzados

Si tu entorno de trabajo no carga módulos del núcleo en tiempo de ejecución, al establecer kernel.modules_disabled=1 tras el arranque se impide que se ejecuten con éxito futuras llamadas a modprobe, lo que cierra de una vez la ruta de autocarga para RDS y todos los demás módulos.

Esta medida es más restrictiva que incluir específicamente a RDS en la lista negra, y solo debe utilizarse cuando no se prevea la carga de módulos en tiempo de ejecución (sin hardware de conexión en caliente, sin módulos de sistemas de archivos o de red bajo demanda, sin entornos de ejecución de contenedores que carguen módulos en el primer uso).

sudo sysctl -w kernel.modules_disabled=1

Ten en cuenta que esta configuración es un cambio irreversible durante el arranque: no se puede restablecer a 0 sin reiniciar el sistema. Comprueba su funcionamiento en un entorno que no sea de producción antes de implementarla.

Comprueba si tu servidor está expuesto

Realice las tres comprobaciones que se indican a continuación y compare los resultados con los criterios que figuran al final de esta sección.

1. ¿Está disponible RDS en la compilación del núcleo?

   grep -E 'CONFIG_(RDS|RDS_TCP|IO_URING)' /boot/config-$(uname -r)
   modprobe -n -v rds_tcp
   ls /lib/modules/$(uname -r)/kernel/net/rds/ 2>/dev/null

2. ¿Está activada la función io_uring?

   cat /proc/sys/kernel/io_uring_disabled

3. ¿Ya están esos módulos en la lista negra?

   grep -rEn '^\s*(blacklist|install)\s+rds' /etc/modprobe.d/ /etc/modules-load.d/ 2>/dev/null

Un host solo es un objetivo válido si se cumplen todas las condiciones siguientes: CONFIG_RDS y CONFIG_RDS_TCP están disponibles, io_uring_disabled es 0 y los módulos rds y rds_tcp no figuran en la lista negra.

Parche sin reinicio de KernelCare

Esta sección se actualiza a medida que se incorporan los parches. Comprueba la fecha y hora que aparece en la línea de actualización al principio de la entrada.

Situación a fecha de 21 de mayo de 2026, a las 12:00 UTC: los parches de KernelCare para todas las distribuciones (excepto Debian 12 y Proxmox 8) se han incorporado al canal principal.

Una vez que esté disponible en el canal de pruebas:

kcarectl --update --prefix test

Una vez validado, el parche se instalará en la próxima ejecución programada, o bien puedes descargarlo cuando lo necesites:

kcarectl --actualizar

Comprueba que se haya aplicado el parche. Una vez asignado un CVE, compruébalo mediante:

kcarectl --patch-info | grep CVE-XXXX-XXXXX   # sustituir por el CVE

A qué hay que estar atento a medida que se desarrolla la situación

• Asignación de CVE (ninguna en el momento de redactar este documento)
• Un aviso oficial de V12 Security o del equipo de seguridad del núcleo
• Actualizaciones del núcleo de las distribuciones Ubuntu, Debian, Amazon Linux, openSUSE, Oracle y Proxmox
• Lanzamiento del parche KernelCare para todas las versiones del núcleo compatibles

Esta publicación se actualizará cuando se asigne el CVE y a medida que los parches de KernelCare pasen de la fase de pruebas a la versión estable. Los clientes de KernelCare recibirán el parche automáticamente una vez que se incorpore al canal principal.

Aplica parches a todos los kernels sin necesidad de reiniciar

Si aún no eres usuario de KernelCare, este es un buen momento para descubrir cómo los parches sin reinicio pueden proteger los sistemas Linux críticos sin necesidad de ventanas de mantenimiento de emergencia ni tiempos de inactividad.

Más información sobre KernelCare aquí →