En el subsistema de criptografía de Linux, se prepara la eliminación del soporte zero-copy del interfaz AF_ALG para tipos de algoritmos SKCIPHER y AEAD. El cambio ya está en el árbol de cryptodev y se espera que se envíe en la ventana de fusión Linux 7.2, que debería abrirse en junio. La razón son las crecientes preocupaciones sobre la seguridad de los mecanismos zero-copy en el núcleo, especialmente después de las recientes vulnerabilidades en el código criptográfico de Linux.
AF_ALG — es interfaz de usuario al API criptográfico del núcleo de Linux. A través de él, los programas pueden acceder a implementaciones de cifrados, hashes y algoritmos AEAD en el núcleo como si fueran sockets. La documentación de Linux describe por separado para AF_ALG el modo zero-copy a través de splice() y vmsplice(), donde el núcleo intenta evitar la copia innecesaria de datos a la memoria del núcleo.
El problema es que, en el caso de AF_ALG, esta ganancia en rendimiento resultó no ser tan importante, y los riesgos son demasiado grandes. El autor del cambio, el desarrollador del subsistema criptográfico de Linux, Eric Biggers de Google, especificé, señala que zero-copy permite que el espacio de usuario ejecute operaciones criptográficas directamente sobre las páginas del caché de archivos, por ejemplo, el binario su, y además crea condiciones para vulnerabilidades TOCTOU, cuando la memoria puede ser modificada simultáneamente con la operación sobre ella.
En otras palabras, un mecanismo útil en la entrada/salida de red o de archivos, en AF_ALG parece ser una optimización demasiado peligrosa. El propio AF_ALG, según el desarrollador, actualmente se conserva principalmente por compatibilidad con un pequeño conjunto de programas, como iwd, que aún no se han trasladado a la criptografía en el espacio de usuario. Originalmente, AF_ALG se pensó también para el acceso a aceleradores criptográficos de hardware, pero en la práctica resultó no ser un interfaz muy eficiente para esta tarea.
Es importante señalar que no se trata de una eliminación completa de splice() o sendfile() para AF_ALG. El cambio se describe como una "ruptura suave" de la compatibilidad: la transmisión de datos en las solicitudes AF_ALG a través de splice() y sendfile() seguirá funcionando, pero ahora el núcleo hará una copia estable interna de los datos antes de la operación criptográfica. El rendimiento en algunos casos puede disminuir, pero la API de usuario formalmente no se rompe.
Se subraya por separado que, por ahora, zero-copy se está eliminando de skcipher y aead. El soporte para el tipo hash será considerado por separado.
El contexto del cambio es desagradable. A finales de abril se reveló una vulnerabilidad Copy Fail (CVE-2026-31431) en algif_aead, es decir, precisamente en la interfaz criptográfica de usuario AF_ALG. Los investigadores mostraron que la combinación de AF_ALG, splice() y las particularidades del procesamiento AEAD permitía a un usuario no privilegiado dañar el caché de páginas, incluidas las páginas correspondientes a binarios setuid, y obtener un aumento de privilegios hasta root.
La aparición Copy Fail estuvo relacionada con la optimización de 2017, que llevó las operaciones AEAD a un procesamiento 'in situ'; al transferir archivos a través de splice() en AF_ALG, el núcleo no trabajaba con una copia, sino con referencias a las páginas del caché de páginas. Como resultado, parte de los datos que se consideraban solo de entrada podrían terminar en un scatterlist escribible.
La eliminación de zero-copy de AF_ALG no es una solución puntual para una sola vulnerabilidad. Más bien, es un intento de eliminar toda una clase de escenarios arriesgados de un UAPI poco utilizado, donde las ventajas de la optimización no justifican la complejidad y las posibles consecuencias. Para los usuarios comunes, el cambio probablemente pasará desapercibido; sin embargo, para programas raros que utilizan activamente AF_ALG a través de splice() o sendfile(), es posible que haya una caída en el rendimiento debido a la copia adicional.
Fuente: linux.org.ru
