Copy Fail technique : AF_ALG, splice et page cache derrière CVE-2026-31431

avril 29, 2026

Illustration technique d'AF_ALG, splice et du page cache dans Copy Fail

Copy Fail, CVE-2026-31431, est une élévation locale de privilèges dans le noyau Linux. En résumé, la combinaison de AF_ALG, splice(), du template cryptographique authencesn et d’une optimisation in-place de algif_aead permet une écriture contrôlée de 4 octets dans le page cache. Pour les équipes sécurité, l’explication utile est opérationnelle : une frontière entre scatterlists a été franchie alors qu’elles n’auraient jamais dû partager une destination inscriptible.

La partie sensible est AF_ALG, l’interface socket qui expose des primitives cryptographiques du noyau à l’espace utilisateur. Avec splice(), l’espace utilisateur peut déplacer des données d’un fichier vers un pipe sans copier chaque octet. Sur ce chemin, le noyau peut conserver des références vers des pages du page cache. Lorsque ces pages sont chaînées dans une scatterlist traitée comme destination par le sous-système crypto, la condition dangereuse apparaît.

Selon l’analyse de Xint Code, authencesn utilise une partie du buffer de destination comme espace temporaire pour réorganiser des octets liés à ESN. Ce comportement était cohérent avec ses hypothèses d’origine, mais il devient dangereux une fois combiné au chemin AF_ALG AEAD in-place introduit plus tard. L’écriture temporaire dépasse la région légitime et atteint des pages représentant la copie en mémoire d’un fichier lisible.

Pourquoi le page cache change l’impact

Le page cache n’est pas une copie privée appartenant au processus attaquant. C’est une représentation en mémoire que d’autres chemins du système peuvent lire. Si cette copie correspond à un binaire setuid, une modification temporaire en mémoire peut influencer son exécution sans modifier le fichier persistant sur disque. Les contrôles fondés uniquement sur le fichier physique ne suffisent donc pas.

Le changement signalé est petit : 4 octets par opération. Mais la taille ne définit pas la sévérité. Une primitive petite, fiable et répétable peut suffire si la cible est sensible. La valeur technique de Copy Fail réside dans la combinaison du contrôle, de la fiabilité et de la portabilité sur les noyaux et distributions affectés, pas dans la taille du PoC.

Cela explique aussi le débat sur la sévérité. La faille nécessite une exécution locale et ne donne pas d’accès distant initial. Plusieurs fournisseurs la classent donc comme moyenne ou modérée. Mais dans les environnements multi-tenant, CI, conteneurs ou sandboxes, la frontière entre “local” et “critique” est mince : l’exécution locale de code est précisément le service fourni.

Le correctif

Le correctif principal ramène algif_aead à un fonctionnement out-of-place. Au lieu de laisser source et destination partager une structure combinée avec des pages du page cache chaînées, le correctif sépare les scatterlists d’entrée et de sortie. Il supprime ainsi la condition qui permettait à l’écriture temporaire de authencesn d’atteindre de la mémoire associée à un fichier.

Pour les opérateurs, le message est clair : mettre à jour le noyau de la distribution vers une version intégrant le correctif. Porter manuellement des commits n’est pas conseillé sauf pour les équipes qui maintiennent leur propre noyau et disposent d’un processus de validation. Dans une flotte classique, l’unité de remédiation est le paquet noyau du fournisseur, l’image de base ou le noyau géré par le cloud.

Comme mitigation temporaire, le site Copy Fail recommande de désactiver algif_aead ou de bloquer la création de sockets AF_ALG avec des politiques comme seccomp pour les workloads non fiables. C’est une réduction de surface raisonnable, surtout pour les runners et sandboxes, mais elle doit être testée. Certains environnements embarqués ou configurations d’offload crypto peuvent dépendre d’AF_ALG.

Checklist défensive

D’abord, inventorier les noyaux réels, pas seulement les distributions. Versions de noyau, backports et builds cloud comptent plus que les noms de produit. Ensuite, identifier les hôtes où utilisateurs, conteneurs ou jobs CI partagent un noyau. Ces systèmes passent avant les serveurs mono-utilisateur.

Troisièmement, vérifier si les politiques de sandbox bloquent les familles de sockets inutiles. De nombreux workloads n’ont jamais besoin d’ouvrir AF_ALG; si votre modèle exécute du code tiers, bloquer les surfaces inutilisées réduit le risque au-delà de cet incident. Quatrièmement, séparer les runners pour le code externe et éviter d’utiliser des hôtes privilégiés pour des pipelines peu fiables.

Cinquièmement, valider avec les avis des fournisseurs. La discussion publique contient des détails utiles, mais aussi des erreurs et divergences, dont la mention débattue d’une version RHEL inexistante sur la page publique. Pour la gestion du changement, les trackers officiels et l’état documenté par plateforme priment.

Ce que le patch ne résout pas

Corriger Copy Fail ne supprime pas le problème général de l’exécution de code non fiable sur des noyaux partagés. Cela ne remplace pas l’isolation forte, le contrôle des syscalls, la séparation des tenants ni la rotation des images de base. La leçon technique est plus large : les optimisations in-place qui mélangent des références d’origines différentes doivent être auditées avec soin lorsque des chemins zero-copy depuis l’espace utilisateur existent.

Les équipes plateforme devraient revoir leurs tests autour de splice(), du page cache, des API crypto exposées à l’espace utilisateur et des sandboxes autorisant des syscalls peu fréquents. Copy Fail montre comment une décision localement raisonnable peut devenir dangereuse quand un autre sous-système change le modèle mémoire des années plus tard.

La conclusion n’est pas la panique, mais la priorité. Là où un attaquant potentiel peut déjà exécuter du code local, une élévation fiable de privilèges n’est pas un détail secondaire. C’est une rupture de frontière de confiance.