Dans le sous-système de cryptographie Linux, la suppression du support est en cours de préparation zero-copy de l'interface AF_ALG pour les types d'algorithmes SKCIPHER et AEAD. Le changement est déjà dans l'arbre cryptodev et devrait être soumis lors de la fenêtre de fusion Linux 7.2, qui devrait s'ouvrir en juin. Cela est dû à des inquiétudes croissantes concernant la sécurité des mécanismes zero-copy dans le noyau, en particulier après les récentes vulnérabilités dans le code cryptographique de Linux.
AF_ALG — ce sont des l'interface utilisateur de l'API cryptographique du noyau Linux. À travers cela, les programmes peuvent accéder aux implémentations de chiffrement, de hachage et d'algorithmes AEAD dans le noyau comme à des sockets. La documentation Linux décrit spécifiquement pour AF_ALG le mode zero-copy via splice() et vmsplice(), où le noyau s'efforce d'éviter des copies de données inutiles en mémoire noyau.
Le problème est que, dans le cas d'AF_ALG, cet avantage de performance n'est pas si important, et les risques sont trop élevés. L'auteur du changement, le développeur du sous-système cryptographique de Linux, Eric Biggers de Google, a indiqué, indique que le zero-copy permet à l'espace utilisateur d'exécuter des opérations cryptographiques directement sur les pages du cache mémoire des fichiers, par exemple d'un binaire su, et crée également des conditions pour des vulnérabilités TOCTOU, où la mémoire peut être modifiée simultanément à l'opération.
En d'autres termes, un mécanisme utile pour l'entrée-sortie réseau ou de fichiers apparaît dans AF_ALG comme une optimisation trop risquée. AF_ALG, selon le développeur, est principalement conservé pour garantir la rétrocompatibilité avec un petit ensemble de programmes, tels que iwd, qui n'ont pas encore été convertis à la cryptographie dans l'espace utilisateur. À l'origine, AF_ALG était également prévu pour accéder aux accélérateurs cryptographiques matériels, mais il s'est avéré être un interface pas très efficace pour cette tâche.
Il est important de noter qu'il ne s'agit pas d'une suppression complète de splice() ou sendfile() pour AF_ALG. Le changement est décrit comme une 'rupture douce' de la compatibilité : le transfert de données dans les requêtes AF_ALG via splice() et sendfile() continuera de fonctionner, mais le noyau effectuera désormais une copie interne stable des données avant l'opération cryptographique. La performance peut diminuer dans certains cas, mais l'API utilisateur n'est pas formellement cassée.
Il est également souligné que, pour le moment, le zero-copy est retiré de skcipher et aead. Le support pour le type hash sera examiné séparément.
Le contexte du changement est désagréable. Fin avril, une vulnérabilité a été révélée Échec de la copie (CVE-2026-31431) dans algif_aead, c'est-à-dire précisément dans l'interface cryptographique utilisateur AF_ALG. Les chercheurs ont montré que la combinaison d'AF_ALG, de splice() et des particularités du traitement AEAD permettait à un utilisateur non privilégié d'endommager la cache de page, y compris les pages correspondant aux binaires setuid, et d'obtenir une élévation de privilèges jusqu'à root.
L'apparition Échec de la copie a été liée à l'optimisation de 2017 qui avait transféré les opérations AEAD vers un traitement « sur place » ; lors du transfert de fichiers via splice() dans AF_ALG, le noyau ne traitait pas une copie, mais des références à des pages de la cache de page. En conséquence, une partie des données qui étaient considérées comme uniquement entrantes pouvait se retrouver dans le scatterlist en écriture.
La suppression du zero-copy de l'AF_ALG n'est pas une correction ciblée d'une seule vulnérabilité. C'est plutôt une tentative d'éliminer toute une catégorie de scénarios à risque dans un UAPI peu utilisé, où les gains d'optimisation ne justifient pas la complexité et les conséquences potentielles. Pour les utilisateurs ordinaires, ce changement restera probablement imperceptible ; pour certaines applications rares qui utilisent activement AF_ALG via splice() ou sendfile(), une dégradation des performances est possible en raison de copies supplémentaires.
Source : linux.org.ru
