La seguridad de Linux nuevamente enfrenta un desafío tras el descubrimiento de la vulnerabilidad CVE-2026-31431, bautizada como «Copy Fail» por los investigadores de Xint Code. Lejos de ser un fallo teórico, este problema de diseño permite a un usuario local sin privilegios elevar sus permisos y obtener acceso total como superusuario de forma predecible y silenciosa.
Los investigadores mencionan que este fallo ha sido explotado con éxito en distribuciones líderes como Ubuntu, Amazon Linux, RHEL y SUSE, confirmando que cualquier sistema que ejecute un kernel posterior a la versión 4.14 y mantenga habilitado el soporte para sockets AF_ALG es potencialmente vulnerable a este ataque.
Operaciones In-Place y el desbordamiento del caché de páginas
Sobre el fallo, se menciona que este se remonta a una optimización introducida en 2017 dentro de la API criptográfica del kernel (AF_ALG). Esta modificación buscaba eliminar el almacenamiento intermedio innecesario ejecutando operaciones de cifrado autenticado (AEAD) directamente en el mismo espacio de memoria, lo que se conoce como operaciones «in-place».
El problema crítico surge al combinar esta optimización con la función splice(), la cual transfiere datos entre descriptores de archivo transfiriendo referencias directas al caché de páginas del kernel en lugar de copiar físicamente los datos. Al solicitar un descifrado, la estructura de memoria se configuraba de tal manera que el búfer de destino, que debería ser un espacio temporal para el usuario, terminaba vinculado directamente a las páginas de la caché que contienen los datos de los archivos del sistema.
Authencesn y la escritura fuera de los límites de memoria
El detonante final de la vulnerabilidad reside en el comportamiento anómalo del algoritmo authencesn. A diferencia de otras rutinas criptográficas que respetan estrictamente los límites de sus búferes de destino, este algoritmo específico utiliza el espacio de memoria del usuario como un área de trabajo temporal (scratch pad) para reorganizar secuencias de bytes durante el cálculo de etiquetas de autenticación.
En este proceso, el algoritmo escribe cuatro bytes más allá del límite establecido para la región de salida. Debido a la optimización in-place y a la cadena de referencias creada por splice(), esta escritura aparentemente inofensiva cruza la frontera de la memoria del usuario y aterriza directamente en la página de la caché del kernel asociada al archivo que se está procesando.
Esta cadena de fallos lógicos otorga al atacante la capacidad de sobrescribir arbitrariamente cuatro bytes en posiciones específicas de la caché de páginas para cualquier archivo que pueda leer. Enviando una serie de solicitudes calculadas, un atacante puede inyectar código malicioso en la versión en memoria de archivos ejecutables críticos con el bit suid activo, como la herramienta de cambio de usuario.
Dado que todas las operaciones de lectura consultan primero la caché de páginas, la próxima vez que se invoque la utilidad legítima, el sistema ejecutará el código inyectado desde la memoria, otorgando privilegios de root instantáneos sin alterar jamás el archivo físico en el disco duro. Más alarmante aún, debido a que el aislamiento de contenedores comparte la caché de páginas del host subyacente, esta vulnerabilidad sirve como una puerta directa para escapar de entornos virtualizados como los clústeres de Kubernetes y comprometer el nodo principal.
Parches de emergencia y soluciones de mitigación
Frente a la gravedad de este fallo, los equipos de mantenimiento han desplegado actualizaciones de emergencia, donde la solución definitiva radica en revertir la optimización in-place dentro del archivo algif_aead.c, separando estrictamente las listas de memoria de origen y destino para evitar que las páginas de la caché terminen en rutas escribibles.
Estos parches ya se han integrado en los kernels 6.18.22, 6.19.12 y 7.0, y están siendo adaptados (backports) a las ramas de soporte a largo plazo. Para aquellos administradores que no puedan reiniciar o actualizar sus servidores de inmediato, se recomienda deshabilitar el módulo del kernel algif_aead si fue compilado externamente, o restringir severamente la creación de sockets AF_ALG mediante políticas de seguridad como SELinux, un blindaje que, por ejemplo, ha mantenido a los dispositivos Android actuales a salvo de esta amenaza.
Finalmente, si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...