# CopyFail (CVE-2026-31431): mitigación automática con Core-Admin

#1

CopyFail (CVE-2026-31431): mitigación automática con Core-Admin

Introducción

CopyFail (CVE-2026-31431) es un fallo de escalada local de privilegios en el kernel Linux que afecta a prácticamente todas las distribuciones mainstream publicadas desde 2017. Un usuario local sin privilegios puede obtener root en menos de un segundo ejecutando un script de Python de 732 bytes.

Mientras los proveedores de las distintas distribuciones publican y despliegan los kernels parcheados (proceso que está en curso durante abril de 2026), Core-Admin ofrece un mecanismo de mitigación automática que cierra el vector de ataque sin necesidad de reiniciar el servidor y sin impacto operativo en el stack típico de hosting (web, correo, base de datos, SSH, VPN, etc.).

Este artículo explica el fallo, qué distribuciones soportadas por Core-Admin están afectadas, el vector de ataque, y cómo Core-Admin detecta, mitiga y verifica la mitigación de forma automática.

Resumen del fallo

CopyFail es un fallo lógico en la plantilla AEAD authencesn(...) del kernel. Combinado con la optimización in-place introducida en algif_aead en 2017, permite a un usuario local sin privilegios concatenar las llamadas socket(AF_ALG) + splice() para obtener una escritura determinista de 4 bytes en la page cache de cualquier fichero legible.

Apuntando esa escritura a un binario setuid (por ejemplo su, passwd o sudo), el atacante consigue ejecución como root.

Dato Valor
Identificador CVE-2026-31431
Tipo de fallo Escalada local de privilegios (LPE)
Privilegios requeridos Usuario local sin privilegios
Componente vulnerable algif_aead (AF_ALG userspace crypto API)
Commit que introduce el fallo 72548b093ee3 (Linux 4.10, febrero 2017)
Commit que lo parchea a664bf3d603d (revierte la optimización in-place)
Impacto Compromiso total del sistema (root)
Complejidad de explotación Muy baja (PoC público disponible)

Vector de ataque

El vector se apoya en la API AF_ALG del kernel Linux, que expone los algoritmos criptográficos del kernel a procesos de espacio de usuario mediante un socket family.

  1. El atacante crea un socket socket(AF_ALG, SOCK_SEQPACKET, 0) y lo enlaza con bind() a la plantilla AEAD authencesn(...).
  2. Al hacer bind(), el kernel invoca request_module() y carga automáticamente el módulo algif_aead (si no estaba cargado ya).
  3. El atacante usa la combinación splice() + la lógica defectuosa de authencesn para forzar al kernel a escribir 4 bytes controlados en la page cache de un fichero de su elección que tenga permiso de lectura (no requiere permiso de escritura).
  4. Eligiendo como objetivo un binario setuid root, modifica el código justo antes de su ejecución y obtiene un shell con privilegios de root.

El detalle relevante es que el ataque no requiere que algif_aead esté cargado previamente: el simple bind(AF_ALG, ...) dispara la auto-carga vía request_module(). Por ese motivo blacklist algif_aead por sí solo no es suficiente como mitigación: blacklist evita la carga en arranque, pero no la auto-carga bajo demanda.

Distribuciones soportadas por Core-Admin

La siguiente tabla lista las distribuciones gestionadas por Core-Admin y su estado frente a CopyFail:

ID Distribución Kernel típico Afectada Nota
239 debian-lenny-amd64 2.6.26 NO (pre-2017) EOL
240 debian-lenny-i686 2.6.26 NO (pre-2017) EOL
242 debian-squeeze-i686 2.6.32 NO (pre-2017) EOL
368 debian-squeeze-amd64 2.6.32 NO (pre-2017) EOL
243 debian-wheezy-amd64 3.2 NO (pre-2017) EOL
244 ubuntu-precise (12.04) 3.2 / 3.13 NO (pre-2017) EOL
246 centos-63-amd64 2.6.32 NO (pre-2017) EOL
238 debian-jessie-amd64 3.16 NO (pre-2017) EOL
245 ubuntu-xenial (16.04) 4.4 / HWE 4.15 DEPENDE 4.4 NO; HWE 4.15+ SÍ
451 centos-7-amd64 3.10 (RHEL) PROBABLE NO Verificar changelog del kernel
283 debian-stretch-amd64 4.9 PROBABLE NO 4.9 < 4.10, salvo backport
287 ubuntu-bionic (18.04) 4.15 / HWE 5.4 SÍ ESM activo
324 debian-buster-amd64 4.19 SÍ LTS
358 ubuntu-focal (20.04) 5.4 / 5.15 HWE SÍ Soporte estándar
395 debian-bullseye-amd64 5.10 SÍ LTS
452 ubuntu-jammy (22.04) 5.15 / 6.5 HWE SÍ Soportada
471 debian-bookworm-amd64 6.1 SÍ Stable actual
490 ubuntu-noble (24.04) 6.8 SÍ LTS actual

Nota importante: la mitigación automática de Core-Admin no usa una lista blanca/negra de distribuciones. La detección es dinámica: combina la versión del kernel (uname -r) con la disponibilidad del módulo algif_aead. Eso significa que si en el futuro el kernel se parchea, la detección dejará automáticamente de marcar el sistema como vulnerable, sin necesidad de actualizar Core-Admin.

Cómo mitiga Core-Admin: el checker security_and_mitigations

Core-Admin incluye un checker llamado security_and_mitigations diseñado específicamente para concentrar mitigaciones de emergencia frente a CVEs críticos a nivel de kernel/userspace. La primera vulnerabilidad cubierta es CopyFail.

El checker se ejecuta de forma periódica en todas las máquinas gestionadas y, para cada CVE registrado:

  1. Detecta si el sistema es vulnerable.
  2. Si lo es, aplica la mitigación (a menos que el operador lo haya desactivado explícitamente).
  3. Verifica que la mitigación está realmente en vigor.
  4. Reporta el peor estado encontrado entre todos los handlers.

Lógica de detección de CopyFail

El checker decide si el sistema está expuesto siguiendo este árbol:

  1. Lee la versión del kernel con uname -r. Si es anterior a 4.10, el sistema no es vulnerable (la optimización defectuosa no existía aún).
  2. Comprueba si algif_aead está actualmente cargado (lsmod). Si lo está, el sistema es vulnerable.
  3. Si no está cargado, ejecuta modprobe -n -v algif_aead (simulación):
    • Si la salida menciona /bin/true, la mitigación ya está aplicada → no vulnerable.
    • Si modprobe no encuentra el módulo, no es alcanzable → no vulnerable.
    • Si simularía un insmod normal, el módulo se cargaría bajo demanda → vulnerable.

Estrategia de mitigación

La mitigación implementa defensa total: bloquea toda la familia AF_ALG de frontends de userspace, no sólo algif_aead. El exploit publicado únicamente usa algif_aead, pero el resto de la familia (algif_skcipher, algif_hash, algif_rng) ha generado CVEs en el pasado y bloquearlos es un coste cero.

La mitigación tiene dos pasos:

Paso 1: fichero /etc/modprobe.d/disable-copyfail.conf 

# Mitigation for CopyFail (CVE-2026-31431)
# Generated by core-admin security_and_mitigations checker.

install algif_aead /bin/true
install algif_skcipher /bin/true
install algif_hash /bin/true
install algif_rng /bin/true

blacklist algif_aead
blacklist algif_skcipher
blacklist algif_hash
blacklist algif_rng

La directiva install ... /bin/true reemplaza la carga del módulo por una operación nula. Esto bloquea tanto la carga manual (modprobe) como la auto-carga vía request_module() que dispara el bind(AF_ALG) del exploit.

La directiva blacklist bloquea adicionalmente la carga en arranque temprano. Las dos son necesarias: ninguna por separado cubre todos los casos.

Paso 2: descarga de los módulos ya cargados

Si alguno de los frontends algif_* está actualmente cargado, el checker ejecuta rmmod para descargarlo. Si el módulo está ocupado (poco frecuente), rmmod falla y la verificación reportará CRITICAL indicando que es necesario reiniciar para que la mitigación quede totalmente efectiva (las nuevas cargas ya están bloqueadas por la regla de modprobe.d).

Verificación

Tras aplicar la mitigación, el checker confirma tres invariantes independientes:

  1. El fichero /etc/modprobe.d/disable-copyfail.conf existe y contiene la directiva install algif_aead /bin/true.
  2. algif_aead no aparece en lsmod.
  3. La salida de modprobe -n -v algif_aead contiene /bin/true.

Si los tres se cumplen, el checker reporta OK con el detalle de que el sistema era vulnerable y la mitigación está aplicada y verificada. Si alguno falla, reporta CRITICAL con el problema concreto.

Impacto operativo: ¿qué se rompe al bloquear algif_*?

AEAD como tal (AES-GCM, ChaCha20-Poly1305, etc.) está en todas partes: TLS 1.3, SSH, WireGuard, IPsec, LUKS2, JWT cifrados, etc. Pero ninguno de esos consumidores usa AF_ALG/algif_aead. Todos pasan por librerías de espacio de usuario (OpenSSL, libsodium, libgcrypt) o por rutas internas del kernel (XFRM, dm-crypt, KTLS).

Software / función Usa algif_aead Impacto
Apache, Nginx (HTTPS vía OpenSSL) No Ninguno
Postfix, Dovecot, Exim (TLS vía OpenSSL/GnuTLS) No Ninguno
MySQL/MariaDB TLS No Ninguno
PHP (extensiones sodium / openssl) No Ninguno
OpenSSH, rsync sobre SSH No Ninguno
OpenVPN, WireGuard, strongSwan No Ninguno
Samba No Ninguno
LUKS / cryptsetup (montaje / desbloqueo) No Ninguno
cryptsetup-reencrypt (re-cifrado online) A veces Evitar durante una operación en curso
iwd (cliente WiFi) Sí No aplica en servidores
tlshd (NFS sobre TLS) A veces Despliegue muy raro
BEEP/Vortex (transporte de Core-Admin) No (TLS) Ninguno

En resumen: en un servidor con un perfil estándar de hosting (web + correo + bases de datos + administración remota), el bloqueo de algif_* tiene riesgo cero.

Opciones del checker en la interfaz de Core-Admin

El checker expone una opción configurable en la UI:

skip_copy_fail_mitigation

  • Tipo: booleano
  • Valor por defecto: false (es decir, mitigación activada)
  • Efecto cuando se pone a true:
    • La detección sigue ejecutándose normalmente.
    • No se aplica la mitigación.
    • No se ejecuta la verificación.
    • El checker reporta OK con el mensaje “CopyFail (CVE-2026-31431) detected, system vulnerable but mitigation skipped”.

Esta opción está pensada para los casos minoritarios en los que el operador necesita realmente mantener algif_* funcional (por ejemplo, una operación activa de cryptsetup-reencrypt) y prefiere asumir el riesgo a la espera del kernel parcheado por la distribución.

image
image.png2104x758 270 KB

Mitigación manual (si se necesitase aplicarla fuera de Core-Admin)

Si por algún motivo no se puede usar la mitigación automática, el mismo cambio se puede aplicar a mano con los siguientes comandos:

# 1. Bloquear futuras cargas (escribe el mismo contenido que el handler).
cat > /etc/modprobe.d/disable-copyfail.conf <<'EOF'
install algif_aead /bin/true
install algif_skcipher /bin/true
install algif_hash /bin/true
install algif_rng /bin/true

blacklist algif_aead
blacklist algif_skcipher
blacklist algif_hash
blacklist algif_rng
EOF
chmod 0644 /etc/modprobe.d/disable-copyfail.conf

# 2. Descargar los módulos ya cargados (si lo están).
for m in algif_aead algif_skcipher algif_hash algif_rng; do
  lsmod | awk '{print $1}' | grep -qx "$m" && rmmod "$m"
done

# 3. Verificar.
modprobe -n -v algif_aead 2>&1 | grep -q '/bin/true' && echo OK
lsmod | grep -E '^algif_' || echo "no algif_* modules loaded"

Revertir la mitigación

Cuando la distribución publique el kernel parcheado y el servidor esté reiniciado con la versión corregida, la mitigación puede retirarse:

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

A partir del siguiente bind(AF_ALG), el módulo algif_aead se cargará de nuevo con normalidad. La siguiente ejecución del checker reportará OK con el motivo system not vulnerable, ya que la detección verá que la condición de explotación ya no se cumple (el commit defectuoso ha sido revertido aguas arriba).

Diseño del checker: extensible a futuros CVEs

El checker security_and_mitigations no está limitado a CopyFail. Está construido como un registro de handlers: cada nueva vulnerabilidad crítica de kernel/userspace se añade como un handler adicional con tres funciones (detect, mitigate, verify) y se registra con register_security_handler(...).

El driver del checker:

  1. Recorre el registro.
  2. Expone en la UI una opción skip__mitigation por cada handler.
  3. Ejecuta detect → mitigate → verify para cada uno.
  4. Devuelve el peor estado encontrado.

Esto permite ir añadiendo cobertura para nuevos CVEs (al estilo Dirty COW, Dirty Pipe, etc.) sin tocar la infraestructura del checker, sólo aportando los tres métodos correspondientes.

Recomendaciones operativas

  1. Mantener el checker activo en todos los servidores gestionados. Por defecto la mitigación se aplica automáticamente y es segura para el stack estándar.
  2. Aplicar las actualizaciones de kernel que las distribuciones están publicando durante abril de 2026. La mitigación es una defensa puente, no un sustituto del parche oficial.
  3. No desactivar skip_copy_fail_mitigation salvo que se tenga un motivo concreto y documentado (por ejemplo, una operación de re-cifrado en curso).
  4. Reiniciar los servidores cuando se haya instalado el kernel parcheado, para que el sistema deje de depender de la mitigación temporal.
  5. Tras reiniciar con el kernel parcheado, retirar el fichero /etc/modprobe.d/disable-copyfail.conf para volver al comportamiento normal del kernel.

Preguntas frecuentes

P: ¿La mitigación requiere reiniciar el servidor?
No, en el caso general. El checker descarga los módulos algif_* con rmmod y bloquea las futuras cargas con modprobe.d, todo en caliente. Sólo se requiere reinicio si alguno de los módulos está ocupado y rmmod falla; en ese caso el checker lo indica explícitamente como CRITICAL.

P: ¿La mitigación rompe TLS, SSH, VPN o el almacenamiento cifrado?
No. Esos servicios usan AEAD a través de OpenSSL, GnuTLS, libsodium o rutas internas del kernel (dm-crypt, XFRM, KTLS). Ninguno pasa por AF_ALG/algif_aead, que es lo único que se bloquea.

P: ¿Qué ocurre si el kernel ya estaba parcheado por la distribución?
La detección verá que el módulo no es alcanzable o que la auto-carga ya está bloqueada por una regla previa, y reportará el sistema como no vulnerable sin aplicar nada.

P: ¿Por qué bloquear toda la familia algif_* y no sólo algif_aead?
El exploit público sólo usa algif_aead, pero los otros frontends (algif_skcipher, algif_hash, algif_rng) pertenecen a la misma familia y han generado CVEs en el pasado. Bloquearlos es coste cero en servidores y aporta defensa en profundidad ante futuras regresiones.

P: ¿Por qué no basta con blacklist?
blacklist sólo bloquea la carga automática en arranque. Cuando un proceso hace bind(AF_ALG, ...), el kernel llama internamente a request_module(), que ignora blacklist. La directiva install ... /bin/true sustituye la carga por una operación nula, y eso sí cierra el vector.

P: ¿Cómo se añadirán mitigaciones para futuros CVEs?
El checker está diseñado para crecer: cada nueva vulnerabilidad se registra como un handler adicional con sus funciones de detección, mitigación y verificación, y se publica en una nueva versión del paquete core-admin. La infraestructura común (driver, opciones de UI, agregación de estado) se reutiliza sin cambios.

Referencias