Copy Fail - CVE-2026-31431

Ce dépôt contient un petit PoC d'élévation de privilèges locale sous Linux pour la CVE-2026-31431, également connue sous le nom de « Copy Fail ».

L'exploit cible le chemin algif_aead du noyau Linux dans l'API crypto utilisateur AF_ALG. Il utilise AF_ALG plus splice() pour forcer le noyau à écrire dans le cache de pages de /usr/bin/su par blocs de 4 octets, puis exécute su après que le cache de pages a été modifié.

Aperçu du code source

Le PoC dans copy_fail_exp.py fait quatre choses :

1. Ouvre une socket AF_ALG pour aead avec la transformation authencesn(hmac(sha256),cbc(aes)).
2. Configure la requête avec les mêmes valeurs setsockopt() utilisées dans la preuve de concept originale.
3. Utilise deux appels splice() pour déplacer les données du fichier cible dans le chemin de requête AF_ALG, qui est le chemin vulnérable du noyau.
4. Décompresse une charge utile intégrée de 160 octets et l'écrit dans le fichier cible par blocs de 4 octets. La charge utile est un stub ELF qui inclut /bin/sh.

Le blob zlib n'est pas des données aléatoires. C'est une charge utile compacte destinée à remplacer le début de /usr/bin/su dans le cache de pages afin que la prochaine exécution de su génère un shell root.

Versions concernées

Le code vulnérable a été introduit dans les modifications algif_aead de l'ère 4.14 du noyau Linux et est resté présent jusqu'au correctif en amont qui annule l'optimisation en place.

Périmètre large

• Noyaux Linux compilés à partir de 2017 qui incluent le chemin en place algif_aead vulnérable.
• La plupart des distributions grand public qui ont livré des noyaux dans cette fenêtre et n'ont pas encore rétroporté le correctif.
• Systèmes où l'API crypto AF_ALG est activée, ce qui est le défaut sur la plupart des distributions Linux généralistes.

Testé / Vérifié publiquement

Points de correction en amont

• 6.18.22
• 6.19.12
• 7.0

Les branches LTS en aval ne sont sûres qu'après que le rétroportage du fournisseur arrive dans le paquet noyau que vous exécutez réellement.

Reproduction

Utilisez une VM de laboratoire ou un hôte conteneurisé qui vous appartient. Ne l'exécutez pas sur des systèmes de production.

1. Démarrez un système avec un noyau vulnérable.
2. Confirmez que /usr/bin/su existe et est setuid-root.
3. Exécutez le PoC :

python3 copy_fail_exp.py

4. Si l'exploit réussit, le script corrige /usr/bin/su puis invoque su. Vous devriez aboutir dans un shell root ou voir une invite root, selon l'environnement.

Exécution

Le script n'a aucune dépendance supplémentaire au-delà de la bibliothèque standard Python 3.

python3 copy_fail_exp.py

Si vous souhaitez d'abord inspecter la cible, le script utilise actuellement /usr/bin/su par défaut.

Application du correctif

Si vous maintenez un noyau en aval, le correctif approprié consiste à rétroporter l'annulation en amont qui supprime l'optimisation AEAD en place :

• Commit de correctif en amont : a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
• Le correctif annule principalement la modification en place antérieure 72548b093ee3.

Flux de travail recommandé pour un arbre de noyau en aval :

git cherry-pick a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
make olddefconfig
make -j"$(nproc)"
make modules_install
make install
reboot

Si vous ne recompilez pas vous-même les noyaux, installez le paquet noyau du fournisseur qui contient le rétroportage et redémarrez dessus.

Atténuation provisoire

Si le correctif est retardé, désactivez le chemin du module comme mesure temporaire :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

Ceci est une atténuation, pas un correctif.

Remarques

• Le PoC est volontairement petit et déterministe.
• L'exploit est uniquement local, mais il a un impact élevé sur les hôtes partagés, les exécuteurs CI, les nœuds Kubernetes et les plateformes de conteneurs car le cache de pages de l'hôte est partagé.
• Le bug du noyau est une erreur logique, pas une condition de course, donc le chemin d'exploitation est fiable une fois que le code vulnérable est présent.