⚠️ CVE-2026-31431: escalada de privilegios en el kernel Linux

Si tienes servidores Linux en tu home lab, en producción, o en cualquier entorno con usuarios no privilegiados, este artículo te interesa. El pasado 30 de abril, CERT-EU publicó el Security Advisory 2026-005 alertando sobre una vulnerabilidad crítica en el kernel Linux que lleva activa desde 2017 sin que nadie la detectara.

¿Qué es CVE-2026-31431?

El CVE-2026-31431, apodado “Copy Fail” por el investigador que lo descubrió, es un fallo de alta severidad con una puntuación CVSS de 7.8. Reside en el módulo algif_aead del kernel Linux, que implementa la interfaz de socket para operaciones criptográficas AEAD (Authenticated Encryption with Associated Data).

La vulnerabilidad proviene de una optimización in-place introducida en 2017 que, bajo ciertas condiciones, permite realizar escrituras controladas en ubicaciones arbitrarias de la memoria. En la práctica, esto significa que un atacante con acceso local sin ningún privilegio especial puede:

1. Abrir un socket AF_ALG para operaciones criptográficas.
2. Usar la llamada al sistema splice() para manipular los buffers internos.
3. Aprovechar el fallo para escribir en memoria privilegiada y elevar sus privilegios a root.

El reporte técnico completo está disponible en copy.fail, donde el investigador documenta el proceso de explotación con detalle.

¿Por qué es tan preocupante?

Porque no requiere ningún privilegio previo. Cualquier usuario local, un proceso dentro de un contenedor, un runner de CI/CD, o una cuenta de servicio con permisos mínimos puede usarlo para convertirse en root. Es el tipo de vulnerabilidad que hace que una brecha inicial pequeña se convierta en un compromiso total del sistema.

Distribuciones afectadas

El fallo afecta a prácticamente todas las distribuciones Linux que tienen el módulo algif_aead disponible, lo que incluye la mayoría de kernels compilados desde 2017:

Excepción notable: Ubuntu 26.04 (Resolute) y versiones posteriores no están afectadas, ya que incluyen la corrección en el kernel de base.

Si tienes nodos de Proxmox, contenedores LXC, o cualquier sistema Linux con kernel compilado en ese rango de fechas, asumir que estás afectado y actuar en consecuencia es lo más sensato.

Estado actual de los parches

⚠️ A fecha de publicación del advisory (30 de abril de 2026), ninguna distribución principal había lanzado aún un paquete de kernel parcheado. Esto significa que actualizar con apt upgrade o dnf update en este momento probablemente no resuelva el problema.

La situación puede haber cambiado desde entonces. Consulta los canales oficiales de seguridad de tu distribución:

• Ubuntu: Ubuntu Security Notices
• Debian: Debian Security Advisories
• RHEL / Rocky / Alma: Red Hat CVE Database
• Amazon Linux: Amazon Linux Security Center
• Arch Linux: Arch Linux Security Advisories

Hasta que llegue el parche oficial, existe una mitigación efectiva que puedes aplicar ahora mismo.

Mitigación inmediata

La solución temporal más directa es deshabilitar la carga del módulo algif_aead. Esto impide que cualquier proceso lo use, eliminando la superficie de ataque.

Ejecuta esto como root en cada sistema afectado:

1

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

Este comando crea una regla en modprobe que bloquea la carga del módulo, incluso si algo intenta cargarlo explícitamente. El cambio persiste entre reinicios porque se guarda en el directorio de configuración de modprobe.

¿Afecta a algo deshabilitar este módulo?

En la inmensa mayoría de los casos, no. El módulo algif_aead solo es necesario para aplicaciones que usan la interfaz AF_ALG del kernel para operaciones criptográficas AEAD, algo relativamente poco común en entornos domésticos o de home lab. Las herramientas de cifrado habituales como OpenSSL o GnuPG no dependen de este módulo para funcionar.

Si tienes aplicaciones específicas de criptografía acelerada por hardware que usan AF_ALG, podrías notar un problema. Pero en ese caso ya sabes que lo usas.

Entornos de contenedores y Kubernetes

En entornos con múltiples tenants o con usuarios no confiables, la prioridad es aún mayor. Los nodos de Kubernetes y los runners de CI/CD son objetivos especialmente atractivos para este tipo de escalada de privilegios, ya que habitualmente ejecutan código de múltiples fuentes.

Además de deshabilitar el módulo en el host, en entornos contenerizados también puedes bloquear la creación de sockets AF_ALG mediante una política de seccomp. Añade esta regla a tu perfil de seccomp personalizado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Esto bloquea la syscall socket cuando el primer argumento es AF_ALG (valor 38), impidiendo que los contenedores puedan iniciar el vector de ataque aunque el módulo esté disponible en el host.

En Docker, puedes aplicarlo con --security-opt seccomp=/ruta/a/perfil.json. En Kubernetes, los SecurityContext con seccomp profiles personalizados son la vía equivalente.

Cómo verificar si el módulo está cargado

Antes de aplicar la mitigación, puedes comprobar si el módulo está actualmente cargado en tu sistema:

1

lsmod | grep algif_aead

Si el comando no devuelve nada, el módulo no está cargado en este momento (aunque podría cargarse bajo demanda si se usa AF_ALG). Si aparece en la lista, está activo y la mitigación es aún más urgente.

Para verificar que la mitigación funciona después de aplicarla:

1

modprobe algif_aead

Con la regla en /etc/modprobe.d/disable-algif.conf activa, este comando debería fallar sin cargar el módulo.

Cuándo llegue el parche oficial

Cuando tu distribución publique un kernel parcheado, el proceso será:

1. Actualizar el kernel con el gestor de paquetes habitual (apt upgrade, dnf update, etc.).
2. Reiniciar el sistema para arrancar con el kernel nuevo.
3. Verificar la versión del kernel activo: uname -r.
4. Una vez confirmado que el kernel parcheado está en uso, eliminar la regla de modprobe:

1

rm /etc/modprobe.d/disable-algif.conf

No hace falta reiniciar para quitar la regla de modprobe, pero sí para aplicar el kernel nuevo. Hazlo todo en el mismo mantenimiento programado.

Impacto en un home lab típico

Si tienes un home lab típico con múltiples contenedores LXC y máquinas virtuales, el vector más probable de ataque sería una escalada desde dentro de un contenedor privilegiado o desde un servicio expuesto a internet que corra como usuario no root.

La buena noticia es que el ataque requiere acceso local al sistema. Si tus servicios no están expuestos directamente a internet sin ninguna capa de seguridad, la superficie real de riesgo es más limitada. Pero eso no significa que puedas ignorarlo: una vulnerabilidad en una aplicación web que te ejecuta código arbitrario puede ser suficiente para que alguien aproveche esto y llegue a root.

Aplicar la mitigación del módulo es rápido, reversible, y en la práctica no rompe nada en un home lab estándar.

Preguntas frecuentes

Compártelo si te ha resultado útil.

¿Tienes sistemas Linux en tu red que hayas parchado o mitigado? Cuéntalo en los comentarios.

Y… hasta aquí por hoy!