Copy Fail – CVE-2026-31431

 (copy.fail)
9 puntos por GN⁺ 2026-04-30 | 5 comentarios | Compartir por WhatsApp
  • Vulnerabilidad de escalación de privilegios con escape de contenedor que permite obtener permisos de root en todas las distribuciones de Linux desde 2017
  • Aprovecha un simple fallo de lógica presente en el módulo criptográfico del kernel de Linux (authencesn) y puede ejecutarse con un solo script de Python de 732 bytes, sin sincronización compleja de tiempos (race condition) ni ajustes por versión del kernel
  • El principio clave consiste en alterar la caché en memoria (page cache) que Linux consulta al ejecutar archivos, enlazando AF_ALG (socket criptográfico del kernel) con splice() (llamada al sistema para copia de datos) para sobrescribir 4 bytes en la copia en caché de un binario setuid
    • El archivo en disco no se modifica, así que se trata de un ataque sigiloso que no deja rastros en una imagen forense del disco
    • Al reiniciar o liberar la memoria, la caché vuelve al original, por lo que la detección posterior con verificaciones tradicionales de integridad de archivos es difícil
  • Como la page cache se comparte en todo el host, en entornos de Kubernetes un solo pod puede explotar esta vulnerabilidad para tomar el control del nodo host y lograr escape de contenedor invadiendo incluso contenedores de otros tenants
  • Se verificó directamente en Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 y SUSE 16, y funciona de inmediato con solo una cuenta local sin privilegios, sin acceso de red ni funciones de depuración del kernel
  • Mientras que las vulnerabilidades previas de escalación de privilegios en Linux (LPE) suelen tener tasas de éxito de 30~80% por intento y funcionar solo en rangos específicos del kernel, Copy Fail apunta a todas las distribuciones durante 9 años (2017~2026) con 100% de éxito en un solo intento
  • A diferencia de Dirty Pipe (abuso de flags del buffer de pipe) y Dirty Cow (requiere carrera de temporización), que pertenecen a la misma familia de alteración de page cache, aquí no hay race condition, no hacen falta offsets por distribución ni recompilar nada, lo que la vuelve mucho más simple y potente
  • Objetivos más urgentes: hosts Linux multi-tenant, clústeres de Kubernetes/contenedores, runners de CI (self-hosted de GitHub Actions, GitLab Runner, etc.), SaaS en la nube que ejecutan código de usuarios: cualquier entorno donde código no confiable se ejecute sobre un kernel compartido
  • La medida prioritaria es aplicar el parche del kernel (commit principal a664bf3d603d), que revierte la optimización in-place introducida en 2017 en el módulo criptográfico para evitar que las páginas de page cache queden incluidas como destino de escritura en operaciones criptográficas
  • Como medida temporal antes del parche, se puede desactivar el módulo algif_aead, sin impacto en funciones criptográficas comunes como dm-crypt/LUKS, kTLS, IPsec o SSH
  • En entornos con cargas no confiables, como contenedores, sandboxes o runners de CI, se recomienda además bloquear con seccomp la creación de sockets AF_ALG independientemente de si ya se aplicó el parche
  • Taeyang Lee de Xint obtuvo la idea inicial de que "la estructura donde splice() entrega páginas de page cache al subsistema criptográfico representa una clase de bugs no explorada", y Xint Code la descubrió como un caso de detección de vulnerabilidades asistida por IA al escanear automáticamente el subsistema crypto/ del kernel en aproximadamente una hora

Lecturas relacionadas

5 comentarios

 
popopo 2026-05-04

Parece que Rocky Linux todavía no tiene parche.

RHEL

AlmaLinux

Rocky Linux

Estoy usando Rock Linux; si no puedes reiniciar, bloquearlo con bpftool desde https://github.com/wgnet/wg.copyfail.patch es efectivo.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Sí hay un parche, pero solo está disponible en el repositorio del servicio de suscripción. La versión CE no está parcheada. (verificado en 9.7 y 10.1)
 
popopo 2026-05-10

El parche salió el 2026-05-05.

El 2026-05-10 hay una nueva opción de seguridad.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

Parece que, al agregar el repositorio de seguridad, es posible aplicar medidas de seguridad por separado de la incorporación del código fuente de RHEL.
 
sukso96100 2026-05-02

Quienes usan Ubuntu probablemente pueden tomar como referencia la guía con el método de mitigación que ya fue publicada.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
Opiniones de Hacker News

  • Desde la perspectiva de alguien que trabaja con el código crypto del kernel de Linux, los exploits de AF_ALG que aparecen periódicamente son realmente frustrantes
    AF_ALG entró al kernel hace mucho tiempo sin suficiente revisión, su estructura es demasiado compleja y además abre una enorme superficie de ataque a programas de userspace sin privilegios
    Encima, es casi innecesario. En userspace ya existe su propio código criptográfico, y el código crypto del kernel originalmente era para usos internos del kernel como dm-crypt
    Incluso authencesn en este exploit es en esencia un detalle de implementación interno de IPsec, así que exponerlo como una API genérica de cifrado/descifrado para userspace me parece que fue un error desde el principio
    Si administras la configuración del kernel de Linux, recomiendo fuertemente desactivar todas las opciones CONFIG_CRYPTO_USER_API_*
    Solo con eso, este bug y una buena parte de los bugs pasados y futuros de AF_ALG no habrían sido explotables
    Si algún programa de userspace se rompe, lo correcto sería ayudar a migrarlo a código crypto de userspace, y de hecho ya hubo casos que cambiaron así
    Desde el principio, AF_ALG no parecía tener mucha utilidad más allá de los exploits
    Tal vez antes este tipo de API para userspace era más o menos tolerable, pero con syzbot o la detección de bugs asistida por LLM que existe hoy, ya es difícil seguir sosteniéndolo

    • Como no sabía qué era AF_ALG, busqué y encontré https://www.chronox.de/libkcapi/html/ch01s02.html, donde sí explican por qué existe
      Se plantea que permite usar desde userspace aceleradores de hardware accesibles solo en modo kernel, que deja pasar claves al kernel sin mantenerlas mucho tiempo en la memoria de la aplicación, y que en entornos con memoria limitada, como sistemas embebidos, puede reducir la huella frente a una librería crypto de userspace
      No sé si eso sea una justificación suficientemente buena, pero al menos sí hay una razón
    • Me pregunto cómo demonios terminó entrando al kernel
      Linus es conocido por ser bastante exigente con lo que acepta en el kernel, así que la historia detrás de una API así debe ser interesante
    • AF_ALG es una interfaz de sockets de Linux que expone la API crypto del kernel a través de descriptores de archivo
      Permite manejar hashes y cifrado mediante llamadas normales a read(2)/write(2)
    • Lo que más me intriga es qué software se rompe al desactivar esta opción del kernel

  • Parece que hubo algo de confusión en el proceso de divulgación
    Los vendors no están tratando esta vulnerabilidad como algo grave, y por eso varias distribuciones siguen sin parchearla
    En https://access.redhat.com/security/cve/cve-2026-31431 aparecía como "Moderate severity" y "Fix deferred", y las páginas de seguimiento de Debian, Ubuntu y SUSE se veían parecidas

    • Desde que el parche entró al kernel, en la práctica atacantes y observadores ya lo conocían desde hacía semanas
      Pero upstream no comunicó claramente que esto fuera una vulnerabilidad, y Linus y Greg tampoco suelen darle demasiado peso conceptual a esa clasificación dentro del kernel
    • Parece que las distribuciones lo consideran de riesgo medio porque requiere acceso local en vez de ejecución remota de código
      Aun así, como permite escalación local a root, en general suena correcto tratarlo como de alta prioridad
      https://ubuntu.com/security/cves/about#priority
    • RedHat ahora ya lo cambió a Important severity y Affected
    • Si uno sigue las propias guías de Ubuntu, esto debería ir como high priority, así que que esté marcado como medium no se ve muy consistente

  • Es una lástima que en el texto principal no se indique enseguida qué versiones del kernel son vulnerables y en cuáles ya quedó parcheado
    Más aún porque es un módulo builtin y no se puede sacar fácilmente con rmmod
    Buscando si el kernel 6.19.14 de Fedora 44 era vulnerable, encontré este mensaje en la lista linux-cve-announce: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    Ahí dice que quedó corregido con esos commits en 6.18.22, 6.19.12 y 7.0, así que sirve como referencia

  • Si quieres comprobar que se aplicó la mitigación recomendada y que el módulo algif_aead quedó bloqueado mediante la configuración de modprobe, no hace falta ejecutar entero ese shell ofuscado
    Con unas pocas líneas de Python como esta puedes verificar de forma legible si el módulo realmente llega a cargarse
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Si la mitigación quedó bien aplicada, modprobe algif_aead también debería fallar con error

  • Seguro que nadie está ejecutando agentes de IA totalmente autónomos con permisos de usuario normal en sistemas operativos afectados
    Si se combina con inyección de prompts zero-day, podría ser bastante catastrófico

    • Mi agente ya corre como root, así que ni me entero del problema
    • Por suerte no convertimos curl | sh en un estándar de facto para instalar cosas en la industria

  • LPE significa local privilege escalation
    Hay demasiadas siglas en seguridad y, aunque por contexto se puede deducir, igual habría sido mejor escribirlo completo la primera vez

    • LPE es una sigla bastante conocida dentro de la comunidad de seguridad, así que no me parece gravísimo que no la hayan desarrollado
      Aun así, si el texto apunta a un público más amplio, estoy de acuerdo en que conviene definirla explícitamente
      Además, todo este texto parece generado por IA
    • Si escribes para un público amplio, lo básico es desarrollar primero las siglas, pero los LLM no suelen seguir bien ese tipo de guía

  • Esto da un poco de risa
    La página dice que funciona en RHEL 14.3, pero esa versión no existe
    RHEL va actualmente por la serie 10.x, así que sentí que me había subido a una TARDIS

    • 14.3 probablemente no es una versión de RHEL sino algo tomado de la versión de GCC de Red Hat
      A veces aparece algo como gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2), y en los ejemplos de abajo se ven rastros parecidos
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • En la misma línea también aparece 6.12.0-124.45.1.el10_1, y eso claramente es un kernel de RHEL 10
      Este tipo de error tipográfico más bien lo comete una persona
      Los números largos copiados y pegados salen bien, y los fáciles se equivocan al teclearlos a mano
    • Perdón, pero eso se va a corregir
      Hubo cierta prisa al recopilar la información para explicar el problema y sí, también había una intención de marketing
      Así que se colaron algunos errores menores; gracias por señalarlo
    • Sí, en cuanto vi la frase "Distribuciones verificadas directamente: RHEL 14.3", la página de lanzamiento ya me sonó a AI slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      Y después de llegar al "Talk to our security experts" al final de la página, hasta me dieron ganas de preguntar si ese experto en seguridad se llamaba Claude

  • En RHEL 9/10, algif_aead no era un módulo sino builtin, así que no se podía descargar
    Como alternativa, encontré una forma de bloquear AF_ALG mediante systemd, aunque requiere un drop-in por cada servicio expuesto
    También hay un playbook de Ansible para cubrir los principales, sshd y user@
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • En RHEL 9/10 también se podía usar initcall_blacklist=algif_aead_init como parámetro de arranque del kernel y luego reiniciar
      Haciéndolo así, el exploit dejó de funcionar
    • Yo pensé en algo parecido, pero bloquearlo servicio por servicio se siente como jugar al whack-a-mole
      Me preocupa qué pasaría con otras rutas de ejecución como cronjob o slurmjob, y estaría bien una forma de hacer que todos los procesos lo hereden a nivel systemd, en vez de configurarlo por servicio individual

  • Parece que este exploit funciona reemplazando un binario SUID para hacer que corra como PID 0
    Pero el sitio afirma que también permite escapar de Kubernetes / clusters de contenedores y de CI runners & build farms, aunque no veo una explicación real que sustente escape de contenedores ni, en particular, escape de user namespace
    Lo probé en Podman rootless y, como era de esperarse, no logró salir del contenedor
    También dicen que "convierte en root a todas las distribuciones Linux lanzadas desde 2017", pero las pruebas reales son solo cuatro y en Alpine no funcionó

    • En el sitio dijeron que pronto publicarían más detalles, así que probablemente los pasos extra o las correcciones salgan en la parte 2
      Ya lo adelantaron con: "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • Esta vulnerabilidad permite sobrescribir bytes en memoria de archivos que se pueden leer, así que sí es fácil imaginar formas de escapar en distintos entornos
    • La afirmación de todas las distribuciones desde 2017 parece basarse en que esta vulnerabilidad entró con un commit de la segunda mitad de 2017
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      Pero la posibilidad real de explotación dependerá de si se trata de una versión major reciente o de un kernel de mantenimiento de una rama vieja
    • Este texto se perjudicó bastante a sí mismo en términos de credibilidad
      Aun así, corrí el PoC directamente en una instancia 24.04 y la vulnerabilidad sí parece real, además de lo bastante seria
      Pero el número de distribuciones afectadas parece mucho menor que lo que afirman, y está bastante lejos de eso de todas las distribuciones desde 2017
      Por ejemplo, si mi interpretación es correcta, Ubuntu tiene algo de impacto incluso en 16.04 EOL, pero el grueso del impacto real parece estar en kernels de vendors que empezaron a distribuirse recientemente, como linux-gcp y linux-oracle-6.7, o sea la línea 6.17
    • Incluso dentro de un contenedor rootless, si logras subir hasta UID 0 real, luego ya podría venir el escape
      Pero harían falta pasos adicionales, y Alpine también podría ser vulnerable en lo esencial aunque solo requiera ajustar el script
      Al final esto no es un exploit universal y acabado, sino un PoC

  • La página en sí se siente algo vibecoded y también tiene pinta de anuncio, pero la vulnerabilidad es real y el nivel de riesgo parece alto
    Explica por qué hoy llegó una actualización de seguridad grande, así que voy a subir la prioridad de actualizar

    • Sí, esto es una publicidad bastante evidente, pero personalmente no me parece mala publicidad
      Encuentran y ayudan a corregir bugs reales, o sea hacen una contribución significativa al ecosistema OSS, y al mismo tiempo venden su propia herramienta de seguridad
    • Esta gente probablemente ya tendría trabajo de sobra incluso sin publicidad
      Pero bueno, hoy en día casi nadie arma páginas web a mano, y si además son desarrolladores del kernel, menos todavía