Host Deep Dive #1 — Copy Fail (CVE-2026-31431): cómo un bug de copia en el kernel puede llevar a root

La CVE-2026-31431 afecta a AF_ALG, la interfaz de sockets criptográficos del kernel Linux. Un proceso sin privilegios puede modificar la caché de páginas y hacer que otros procesos lean un contenido distinto al que está en disco.

José Eduardo Morini Castro8 min
Portada del Host Deep Dive #1 con el título "Copy Fail", un cursor de terminal azul y el identificador CVE-2026-31431.Portada del Host Deep Dive #1 con el título "Copy Fail", un cursor de terminal azul y el identificador CVE-2026-31431.

“Copy Fail” es el nombre que recibe la vulnerabilidad CVE-2026-31431, un fallo de escalada de privilegios en el kernel Linux.

En pocas palabras, permite que un proceso sin privilegios consiga que el kernel modifique temporalmente el contenido de un archivo en memoria. El archivo en disco puede permanecer intacto, mientras que otros procesos terminan viendo la versión modificada que está en la caché.

En determinadas condiciones, este comportamiento se puede aprovechar para alterar el código de un programa privilegiado y pasar de ejecutar código como un usuario normal a hacerlo como root.

La vulnerabilidad se introdujo en 2017, durante el desarrollo del kernel Linux 4.14, y estuvo presente durante unos nueve años en distintas versiones y distribuciones. Se corrigió en 2026, y también se publicaron parches para varias ramas del kernel que siguen recibiendo mantenimiento.

Como afecta a un componente del propio kernel, el problema no se limita a una sola distribución. Sistemas Linux como Ubuntu, Debian, Red Hat, SUSE y Amazon Linux pueden ser vulnerables si utilizan un kernel afectado que aún no se ha actualizado con el parche.

La descubrió Taeyang Lee, investigador de la empresa de seguridad Theori. La divulgación pública tuvo lugar el 29 de abril de 2026.

Dónde está el fallo

La vulnerabilidad está en AF_ALG, una interfaz de Linux que permite a los programas utilizar operaciones criptográficas implementadas por el kernel.

Podemos pensar en AF_ALG como una forma de que una aplicación le diga al kernel:

“Kernel, realiza esta operación criptográfica por mí.”

El código afectado se encuentra en el módulo algif_aead.

El problema aparece en la ruta que se utiliza para mover los datos de esa operación. En determinadas condiciones, una escritura destinada a un búfer concreto puede terminar afectando a páginas que pertenecen a la caché de páginas.

¿Y qué es la caché de páginas, o page cache?

Es una zona de la memoria RAM que Linux utiliza para guardar temporalmente datos de archivos.

Por ejemplo, cuando un programa lee archivo.txt, el kernel puede cargar su contenido en memoria:

DISCO
  │
  │ lee el archivo
  ▼
┌──────────────────┐
│ CACHÉ DE PÁGINAS │
│       RAM        │
└────────┬─────────┘
         │
         ▼
      programa

Si otro proceso necesita leer el mismo archivo, el kernel puede reutilizar esos datos que ya están en RAM en lugar de volver a acceder al disco.

Copy Fail se aprovecha precisamente de ese mecanismo.

Por qué el archivo “cambia” sin escribir en disco

Este es uno de los detalles más importantes de la vulnerabilidad.

Imaginemos que tenemos un archivo en disco:

DISCO
/usr/bin/programa
[ contenido original ]

El kernel puede tener una página de ese archivo en la caché de páginas:

RAM
CACHÉ DE PÁGINAS
[ contenido original ]

Con Copy Fail, esa página en memoria se puede modificar:

DISCO
[ contenido original ]

RAM
CACHÉ DE PÁGINAS
[ contenido MODIFICADO ]

No hace falta que el archivo en disco haya cambiado.

El problema es que el kernel puede seguir utilizando esa página en memoria para atender nuevas lecturas.

Así, un proceso puede pedir que se lea /usr/bin/programa y recibir el contenido que está en ese momento en la caché de páginas, aunque sea distinto del que está guardado en disco.

Es como si, temporalmente, hubiera dos versiones del mismo archivo:

             DISCO
               │
               │ contenido original
               ▼
      ┌──────────────────┐
      │     ARCHIVO      │
      └──────────────────┘

              RAM
               │
               │ contenido modificado
               ▼
      ┌──────────────────┐
      │ CACHÉ DE PÁGINAS │
      └──────────────────┘

Esa diferencia entre lo que está en disco y lo que el kernel tiene en memoria es fundamental para entender Copy Fail.

Cómo se convierte en una escalada de privilegios

Hasta aquí, solo tenemos una modificación de datos en memoria.

Para convertirla en una escalada de privilegios, es necesario alcanzar un archivo que cumpla una función especial.

Uno de los posibles objetivos son los ejecutables setuid.

En Linux, un usuario normal puede ejecutar un programa con setuid, pero el proceso puede iniciarse con los privilegios del propietario del archivo.

Cuando ese propietario es root, el flujo se parece a esto:

usuario normal
      │
      ▼
programa setuid
      │
      ▼
proceso con privilegios de root

Normalmente, el usuario no puede modificar el código de ese programa.

Copy Fail crea una situación diferente:

usuario normal
      │
      ▼
aprovecha el fallo
      │
      ▼
modifica una página de la caché
      │
      ▼
programa privilegiado
      │
      ▼
ejecuta el contenido modificado
      │
      ▼
privilegios elevados

La clave es que el atacante no necesita modificar necesariamente el archivo en disco.

Se aprovecha de que el programa puede cargarse desde una página que ya ha sido alterada en memoria.

Por eso una pequeña corrupción de memoria puede acabar teniendo un impacto mucho mayor.

Por qué es una escalada local

Copy Fail no es una vulnerabilidad de ejecución remota de código.

Por sí sola, no permite que alguien en internet envíe una petición a un servidor y se convierta en root.

El escenario se parece más a este:

1. el atacante consigue ejecutar código
              │
              ▼
2. el código se ejecuta como usuario normal
              │
              ▼
3. aprovecha Copy Fail
              │
              ▼
4. manipula la caché de páginas
              │
              ▼
5. consigue elevar sus privilegios

Es decir, el atacante normalmente ya necesita tener alguna forma de ejecutar código en la máquina.

Esto puede ocurrir, por ejemplo, tras comprometer una cuenta, una aplicación vulnerable u otro componente que permita ejecutar código.

Copy Fail entra en una segunda etapa: pasar de un contexto con pocos privilegios a uno privilegiado.

Por qué importa AF_ALG

AF_ALG es una interfaz de sockets que permite acceder a las funciones criptográficas del kernel Linux.

Un programa puede abrir un socket de este tipo y utilizar operaciones criptográficas sin tener que implementar toda la operación en el espacio de usuario.

El flujo simplificado es el siguiente:

Aplicación
    │
    │ AF_ALG
    ▼
Kernel Linux
    │
    ▼
Subsistema de criptografía

El fallo de Copy Fail aparece en una de las rutas internas que utiliza esta interfaz.

El código vulnerable está relacionado con el módulo algif_aead.

Un proceso sin privilegios que pueda acceder a esa ruta puede aprovechar el comportamiento incorrecto de la operación de copia.

Qué hace interesante a Copy Fail

A primera vista, hablamos de algo relativamente pequeño:

una operación de copia
        ↓
una página de memoria
        ↓
unos pocos bytes modificados

Pero esa página puede contener parte de un archivo en el que otro proceso confía.

Entonces, la cadena puede convertirse en esto:

fallo en el kernel
     ↓
modificación de la caché de páginas
     ↓
contenido del archivo distinto en memoria
     ↓
otro proceso lee el contenido modificado
     ↓
se altera código privilegiado
     ↓
escalada de privilegios

Por eso los fallos del kernel que parecen pequeños pueden tener consecuencias graves.

Cómo probarlo

La divulgación pública de la vulnerabilidad está disponible en copy.fail.

Para estudiar su comportamiento, conviene utilizar un laboratorio aislado y desechable, como una máquina virtual creada específicamente para las pruebas.

También hay que recordar que no es necesario reproducir el exploit para comprobar si un sistema está protegido.

El primer paso debe ser revisar la versión del kernel e instalar las actualizaciones de seguridad que proporciona la distribución.

Cómo protegerse

La medida principal es actualizar el kernel Linux a una versión que incluya la corrección de la CVE-2026-31431.

En entornos Docker también hay mitigaciones específicas para impedir que los contenedores accedan a la ruta vulnerable. Docker publicó sus propias correcciones y recomendaciones para este problema.

El enfoque es el siguiente:

             CORRECCIÓN
                 │
                 ▼
       Kernel con el parche
                 │
                 +
                 │
            MITIGACIONES
                 │
                 ▼
        Docker / seccomp /
        AppArmor / SELinux

La corrección del kernel es la medida principal. Las mitigaciones de aislamiento añaden una capa de defensa.

Para cerrar

Un proceso sin privilegios aprovecha un fallo del kernel para modificar temporalmente, en memoria, el contenido de un archivo guardado en la caché de páginas.

Si un proceso privilegiado utiliza ese archivo, la modificación puede convertirse en una escalada de privilegios.

La idea central es esta:

AF_ALG
  │
  ▼
fallo en el kernel
  │
  ▼
modificación de la caché de páginas
  │
  ▼
contenido del archivo alterado en RAM
  │
  ▼
proceso privilegiado
  │
  ▼
escalada de privilegios

El detalle esencial es ese: el atacante no necesita modificar necesariamente el archivo en disco para cambiar lo que lee otro proceso. El objetivo de la vulnerabilidad es la copia que el kernel conserva en memoria.

Encuentra Copy Fail en tus hosts con runtz

Escanea todos tus hosts ahora. Empieza en runtz.dev.