Copy Fail técnico: AF_ALG, splice y page cache detrás de CVE-2026-31431

abril 29, 2026

Ilustración técnica de AF_ALG, splice y page cache en Copy Fail

Copy Fail, CVE-2026-31431, es una vulnerabilidad de escalada local de privilegios en el kernel de Linux. La explicación corta es que una combinación entre AF_ALG, splice(), el template criptográfico authencesn y una optimización in-place de algif_aead permite una escritura controlada de 4 bytes sobre page cache. La explicación útil para equipos de seguridad es menos espectacular y más operacional: no se trata de magia, sino de una violación de límites entre scatterlists que nunca debieron compartir destino escribible.

El punto delicado es AF_ALG, la interfaz de sockets que expone primitivas criptográficas del kernel a userspace. Con splice(), userspace puede mover datos desde un archivo hacia una tubería sin copiar el contenido byte a byte. En ese recorrido, el kernel puede conservar referencias a páginas del page cache. Cuando esas páginas terminan encadenadas en una scatterlist que el subsistema criptográfico trata como destino, aparece la condición peligrosa.

Según el análisis de Xint Code, authencesn usa parte del buffer de destino como espacio temporal para reordenar bytes relacionados con ESN. Ese comportamiento era razonable dentro de los supuestos originales de uso, pero se volvió peligroso al combinarse con el camino AF_ALG AEAD in-place introducido años antes. La escritura temporal termina fuera de la región legítima y alcanza páginas que representan la copia en memoria de un archivo legible.

Por qué page cache cambia el impacto

La page cache no es una copia privada del proceso atacante. Es la representación en memoria que otros caminos del sistema pueden leer. Si esa copia corresponde a un binario setuid, un cambio temporal en memoria puede afectar la ejecución del binario sin modificar el archivo persistente en disco. Por eso las comprobaciones basadas sólo en el archivo físico no bastan para razonar sobre el impacto.

El cambio reportado es pequeño: 4 bytes por operación. Pero el tamaño no define por sí solo la severidad. Una primitiva pequeña, confiable y repetible puede ser suficiente si el objetivo es un punto sensible. El valor técnico de Copy Fail está en la combinación de control, confiabilidad y portabilidad entre kernels/distribuciones afectadas, no en el tamaño de un PoC.

También explica por qué el debate de severidad es razonable. Requiere ejecución local y no entrega acceso remoto inicial. Eso empuja a varios vendors hacia una prioridad media o moderada. Al mismo tiempo, en entornos multi-tenant, CI, contenedores o sandboxes, la frontera entre “local” y “crítico” es mucho más delgada: ejecutar código local es precisamente el servicio que esas plataformas ofrecen.

La corrección

La corrección principal vuelve a operación out-of-place en algif_aead. En vez de permitir que origen y destino compartan una estructura combinada con páginas del page cache encadenadas, el fix separa las scatterlists de entrada y salida. Esa decisión elimina la condición que permitía que el write temporal de authencesn alcanzara memoria asociada al archivo.

Para operadores, el mensaje práctico es claro: la mitigación preferida es actualizar el kernel de la distribución a una versión que incorpore el fix. No conviene portar manualmente commits salvo que el equipo mantenga su propio kernel y tenga proceso de validación. En flotas normales, la unidad de remediación es el paquete de kernel del vendor, la AMI/base image o el kernel gestionado del proveedor cloud.

Como mitigación temporal, el sitio de Copy Fail recomienda deshabilitar algif_aead o bloquear creación de sockets AF_ALG con políticas como seccomp para workloads no confiables. Esa idea es razonable como reducción de superficie, especialmente en runners y sandboxes, pero debe probarse. Algunos entornos embebidos o configuraciones explícitas de offload criptográfico podrían depender de AF_ALG.

Checklist defensivo

Primero, inventaria kernels reales, no sólo distribución. Las versiones de kernel, backports y builds cloud importan más que el nombre comercial del sistema. Segundo, identifica hosts donde usuarios, contenedores o jobs de CI comparten kernel. Esos sistemas tienen prioridad sobre servidores monousuario.

Tercero, revisa si tus políticas de sandbox bloquean familias de sockets innecesarias. Muchas cargas de trabajo no necesitan abrir AF_ALG; si tu modelo ejecuta código de terceros, bloquear lo no usado reduce el radio de explotación incluso después de este incidente. Cuarto, separa runners para código externo y evita reutilizar hosts privilegiados para PRs o pipelines de baja confianza.

Quinto, valida con el advisory del vendor. La conversación pública contiene detalles útiles, pero también errores y discrepancias, incluida la mención discutida de una versión inexistente de RHEL en la página pública. Para gestión de cambios, usa trackers oficiales y registra el estado por plataforma.

Qué no resuelve el parche

Parchear Copy Fail no elimina el problema general de ejecutar código no confiable en kernels compartidos. Tampoco reemplaza aislamiento fuerte, control de syscalls, separación de tenants ni rotación de imágenes base. La lección técnica es más amplia: optimizaciones in-place que mezclan referencias de distinto origen deben auditarse con especial cuidado cuando existen caminos zero-copy desde userspace.

Para equipos que mantienen plataformas, conviene revisar pruebas de regresión alrededor de splice(), page cache, APIs criptográficas expuestas a userspace y sandboxes que permiten syscalls poco usadas. Copy Fail muestra que una decisión localmente razonable puede volverse peligrosa cuando otro subsistema cambia el modelo de memoria años después.

El resultado final no requiere dramatismo. Sí exige prioridad donde el atacante potencial ya puede ejecutar código local: CI, multi-tenant Linux, Kubernetes, escritorios compartidos y hosts de desarrollo. En esos lugares, una escalada local confiable no es un detalle secundario; es una falla en el límite de confianza.