Un fallo lógico en el subsistema criptográfico del kernel de Linux lleva casi una década explotable sin que nadie lo detectara. Lo encontró una IA en aproximadamente una hora de análisis. El resultado: cualquier usuario sin privilegios puede obtener acceso root en prácticamente cualquier distribución Linux lanzada entre 2017 y el parche publicado en abril de 2026.
El CVE asignado es el CVE-2026-31431 y la vulnerabilidad se conoce como Copy Fail. La web oficial con toda la información, el exploit y la mitigación está en copy.fail.
Qué es Copy Fail y por qué es diferente a otras LPE
La mayoría de vulnerabilidades de escalada de privilegios en Linux dependen de condiciones de carrera o de offsets específicos por distribución, lo que limita bastante su alcance real. Copy Fail no necesita ninguna de las dos cosas. Es un fallo lógico en línea recta: el módulo authencesn del subsistema criptográfico utiliza el buffer de destino del llamante como zona de trabajo temporal y escribe 4 bytes fuera de la región legítima de salida sin restaurarlos. Combinado con AF_ALG y splice(), esos 4 bytes acaban aterrizando en la caché de páginas del kernel sobre cualquier binario setuid legible por el usuario.
El exploit completo son 732 bytes de Python 3, sin dependencias externas, y funciona sin modificaciones en Ubuntu, Amazon Linux, RHEL y SUSE. No hay offsets, no hay recompilación, no hay ventana de carrera que ganar: o funciona o no funciona, y según los tests siempre funciona.
Qué lo hace especialmente peligroso
Lo que distingue a Copy Fail de la mayoría de CVEs de LPE es la combinación de cuatro propiedades que casi nunca aparecen juntas: es portable entre distribuciones sin adaptación, es diminuto y sin dependencias, es silencioso porque la escritura en caché nunca marca la página como sucia (nada llega a disco, en una imagen forense el archivo aparece intacto), y además es un primitivo de escape de contenedores porque la caché de páginas es compartida en todo el host.
Esto último es lo que convierte un problema serio en un problema crítico para entornos multi-tenant: cualquier pod en un cluster Kubernetes, cualquier runner de CI que ejecute código de una PR no confiable, cualquier notebook compartido o función serverless, tiene el mismo problema que un servidor de producción con múltiples usuarios.
Cómo mitigarlo si no puedes parchear todavía
El parche ya está en mainline (commit a664bf3d603d) y las principales distribuciones están sacando kernels actualizados. Si no puedes parchear de inmediato, la mitigación es deshabilitar el módulo algif_aead:
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead 2>/dev/null || truePara la inmensa mayoría de sistemas esto no rompe nada. AF_ALG no es utilizado por dm-crypt/LUKS, IPsec, kTLS, OpenSSL por defecto ni SSH. Si tienes dudas, lsof | grep AF_ALG resuelve la pregunta en un segundo.
El papel de la IA en el descubrimiento
La vulnerabilidad la encontró Xint Code, una herramienta de auditoría basada en IA. El punto de partida fue humano: Taeyang Lee identificó que splice() puede meter páginas de caché en el subsistema criptográfico y que la procedencia de las páginas en scatterlists era una clase de bugs poco explorada. A partir de ahí, la IA hizo el barrido completo del directorio crypto/ del kernel en alrededor de una hora y Copy Fail fue el hallazgo más grave de esa pasada. No es el único: el resto todavía está en proceso de divulgación coordinada.
Web oficial con el exploit, write-up técnico y timeline completo: https://copy.fail/
Únete a la comunidad Sinologic
Crea tu cuenta gratuita y participa en las conversaciones sobre VoIP, Asterisk, Kamailio y telecomunicaciones IP.
¿Tienes un truco mejor?
Compartir conocimiento es la mejor forma de aprender.