Copy Fail – CVE-2026-31431

 (copy.fail)
9 points par GN⁺ 2026-04-30 | 5 commentaires | Partager sur WhatsApp
  • Une vulnérabilité d’élévation de privilèges avec échappement de conteneur permettant d’obtenir les privilèges root sur toutes les distributions Linux depuis 2017
  • Elle exploite un simple défaut logique présent dans le module cryptographique du noyau Linux (authencesn) et peut être exécutée avec un unique script Python de 732 octets, sans synchronisation complexe (race condition) ni ajustement selon la version du noyau
  • Le principe central consiste à altérer le cache mémoire interne (page cache) auquel Linux se réfère lors de l’exécution d’un fichier, en reliant AF_ALG (socket cryptographique du noyau) et splice() (appel système de copie de données) pour écraser 4 octets dans la copie en cache d’un binaire setuid
    • Le fichier réel sur disque n’est pas modifié, ce qui en fait une attaque furtive qui ne laisse pas de trace dans une image disque forensique
    • Après redémarrage ou libération de la mémoire, le cache revient à l’original, rendant la détection a posteriori difficile avec les contrôles traditionnels d’intégrité des fichiers
  • Comme le page cache est partagé à l’échelle de tout l’hôte, dans un environnement Kubernetes, un seul pod exploitant cette faille peut prendre le contrôle du nœud hôte et s’échapper du conteneur jusqu’à compromettre ceux d’autres tenants
  • La faille a été vérifiée directement sur Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 et SUSE 16, et fonctionne immédiatement avec un simple compte local non privilégié, sans accès réseau ni fonctions de débogage du noyau
  • Alors que les vulnérabilités Linux d’élévation de privilèges (LPE) existantes n’affichent souvent qu’un taux de réussite de 30 à 80 % par tentative et ne fonctionnent que sur certaines plages de noyaux, Copy Fail vise toutes les distributions pendant 9 ans (2017~2026) avec 100 % de réussite en une seule tentative
  • Contrairement à Dirty Pipe (abus des flags de buffer de pipe) et Dirty Cow (nécessite une course temporelle), qui relèvent de la même famille d’altération du page cache, l’absence de race condition, d’offsets spécifiques aux distributions et de recompilation rend l’attaque bien plus simple et puissante
  • Cibles les plus urgentes : hôtes Linux multitenants, clusters Kubernetes/conteneurs, runners CI (GitHub Actions auto-hébergé, GitLab Runner, etc.), SaaS cloud exécutant du code utilisateur — en bref, tout environnement où du code non fiable s’exécute sur un noyau partagé
  • Mesure prioritaire absolue : appliquer le patch noyau (commit mainline a664bf3d603d) — il annule l’optimisation in-place introduite en 2017 dans le module cryptographique afin que les pages du page cache ne puissent plus être ciblées en écriture par les opérations cryptographiques
  • En mesure temporaire avant correctif, il est possible de désactiver le module algif_aead, sans impact sur les fonctions de chiffrement courantes comme dm-crypt/LUKS, kTLS, IPsec ou SSH
  • Dans les environnements à workloads non fiables comme les conteneurs, sandboxes ou runners CI, il est recommandé, patch ou non, de bloquer la création de sockets AF_ALG via seccomp
  • Cas de détection de vulnérabilité assistée par IA : Taeyang Lee de Xint a eu l’intuition initiale que « la structure par laquelle splice() transmet des pages du page cache au sous-système de chiffrement constitue une classe de bugs encore inexplorée », puis Xint Code a automatiquement scanné le sous-système crypto/ du noyau et découvert la faille en environ une heure

À lire aussi

5 commentaires

 
popopo 2026-05-04

Il semble que Rocky Linux n’ait pas encore de correctif.

RHEL

AlmaLinux

Rocky Linux

J’utilise Rocky Linux, et si vous ne pouvez pas redémarrer, le blocage via bpftool de https://github.com/wgnet/wg.copyfail.patch est efficace.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Il existe bien un correctif, mais il n’est fourni que via le dépôt du service par abonnement. La version CE n’est pas corrigée. (9.7, 10.1 vérifiés)
 
popopo 2026-05-10

Le correctif est sorti le 2026-05-05.

Une nouvelle option de sécurité est disponible depuis le 2026-05-10.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

En ajoutant le dépôt de sécurité, il semble possible d’appliquer des mesures de sécurité indépendamment de l’intégration des sources RHEL.
 
sukso96100 2026-05-02

Pour les utilisateurs d’Ubuntu, un guide expliquant la marche à suivre a été publié, cela devrait donc vous être utile.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
Commentaires Hacker News

  • Du point de vue de quelqu’un qui travaille sur le code crypto du noyau Linux, les exploits AF_ALG qui reviennent régulièrement sont vraiment exaspérants
    AF_ALG est entré dans le noyau il y a longtemps sans revue suffisante, sa structure est bien trop complexe, et il ouvre une énorme surface d’attaque à des programmes userspace non privilégiés
    En plus, c’est presque inutile. Le userspace a déjà son propre code de chiffrement, et le code crypto du noyau était à l’origine destiné à des usages internes au noyau comme dm-crypt
    Même authencesn dans cet exploit n’est en pratique qu’un détail d’implémentation interne d’IPsec, et l’exposer comme API générique de chiffrement/déchiffrement pour le userspace me paraît avoir été une erreur dès le départ
    Si vous gérez la configuration du noyau Linux, je recommande fortement de désactiver toutes les options CONFIG_CRYPTO_USER_API_*
    Rien que cela aurait rendu inexploitables non seulement ce bug, mais aussi une bonne partie des bugs AF_ALG passés et futurs
    Si un programme userspace casse, mieux vaut l’aider à migrer vers du code crypto userspace, et dans les faits certains l’ont déjà fait
    Au fond, AF_ALG n’a jamais eu beaucoup d’utilité en dehors des exploits
    On tolérait peut-être encore ce genre d’API userspace autrefois, mais avec syzbot et la détection de bugs assistée par LLM aujourd’hui, ça devient difficilement tenable

    • Comme je ne savais pas ce qu’était AF_ALG, j’ai cherché et je suis tombé sur https://www.chronox.de/libkcapi/html/ch01s02.html, où quelques justifications de son existence sont données
      Il est avancé que cela permet d’utiliser depuis le userspace des accélérateurs matériels normalement accessibles uniquement en mode noyau, de transmettre les clés au noyau sans les laisser longtemps dans la mémoire de l’application, et de réduire l’empreinte mémoire par rapport à une bibliothèque crypto userspace dans des environnements contraints comme l’embarqué
      Je ne sais pas si cela constitue une justification suffisante, mais il y a au moins une raison d’être
    • Je me demande comment ça a bien pu entrer dans le noyau
      Linus est réputé assez exigeant sur ce qui entre dans le noyau, donc l’histoire derrière l’arrivée d’une API comme celle-ci serait intéressante
    • AF_ALG est une interface socket Linux qui expose l’API crypto du noyau via des descripteurs de fichier
      Elle permet de manipuler le hachage et le chiffrement au moyen d’appels read(2)/write(2) ordinaires
    • Ce qui m’intéresse le plus, c’est quels logiciels casseraient si on désactive cette option du noyau

  • Il semble y avoir eu une certaine confusion dans le processus de divulgation
    Les éditeurs ne semblent pas traiter cette vulnérabilité comme particulièrement grave, et plusieurs distributions restent donc sans correctif pour l’instant
    https://access.redhat.com/security/cve/cve-2026-31431 l’indiquait comme "Moderate severity" et "Fix deferred", et les pages de suivi de Debian, Ubuntu et SUSE semblaient similaires

    • À partir du moment où le patch est entré dans le noyau, c’était de fait déjà connu des attaquants ou des observateurs depuis plusieurs semaines
      Mais l’upstream n’a pas communiqué clairement dessus comme sur une vulnérabilité, et Linus comme Greg n’accordent généralement pas une grande importance conceptuelle à ce type de classification dans le noyau
    • Si les distributions le classent en risque moyen, c’est sans doute parce qu’il faut un accès local et non une exécution de code à distance
      Cela dit, comme cela permet tout de même une élévation locale de privilèges vers root, cela semble en général mériter une priorité élevée
      https://ubuntu.com/security/cves/about#priority
    • Red Hat l’a maintenant reclassé en Important severity et Affected
    • En regardant les directives propres à Ubuntu, cela semble devoir relever d’une priorité high, mais l’étiquette réelle est medium, ce qui donne une impression d’incohérence

  • C’est dommage que l’article n’indique pas directement quelles versions du noyau sont vulnérables et à partir de quelles versions c’est corrigé
    D’autant plus que c’est un module builtin qu’on ne peut pas simplement retirer avec rmmod
    En cherchant à vérifier si le kernel 6.19.14 de Fedora 44 était vulnérable, je suis tombé sur ce message de la liste linux-cve-announce : https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    Il y est indiqué que cela a été corrigé dans 6.18.22, 6.19.12 et 7.0 via les commits correspondants, ce qui est utile

  • Si vous voulez vérifier si le module algif_aead a bien été bloqué via la configuration modprobe comme le recommande la mesure d’atténuation, pas besoin d’exécuter tout un morceau de shell obfusqué
    Quelques lignes de Python suffisent pour vérifier lisiblement si le module se charge réellement :
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Si l’atténuation est correctement appliquée, modprobe algif_aead devrait aussi échouer avec une erreur

  • J’imagine que personne n’exécute d’agents IA totalement autonomes avec des privilèges utilisateur ordinaires sur des systèmes affectés
    Combiné à une injection de prompt zero-day, ça pourrait être assez catastrophique

    • Mon agent tourne déjà en root, donc je ne vois pas le problème
    • Heureusement qu’on n’a pas fait de curl | sh un standard de fait dans l’industrie

  • LPE signifie local privilege escalation
    Il y a vraiment trop d’acronymes en sécurité, et même si on peut le déduire du contexte, j’aurais préféré que ce soit explicité au moins la première fois

    • LPE est un acronyme assez largement connu dans la communauté sécurité, donc ce n’est pas non plus scandaleux de ne pas l’avoir développé
      Cela dit, pour un texte destiné à un public plus large, je suis d’accord qu’il vaudrait mieux le définir explicitement
      D’ailleurs, tout cet article donne aussi l’impression d’avoir été généré par IA
    • Quand on écrit pour un large public, développer d’abord les acronymes est la base, mais les LLM ont tendance à mal suivre ce genre de consignes

  • C’est assez drôle
    La page dit que ça fonctionne sur RHEL 14.3, mais cette version n’existe pas
    RHEL en est actuellement à la 10.x, donc j’ai eu l’impression d’être monté dans le TARDIS

    • 14.3 semble venir non pas d’une version de RHEL, mais d’un numéro de version GCC côté Red Hat
      On peut voir des chaînes du type gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2), et on retrouve des traces similaires dans les exemples ci-dessous
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • La même ligne mentionne aussi 6.12.0-124.45.1.el10_1, qui est manifestement un noyau RHEL 10
      Ce genre de faute de frappe est au contraire très humain
      Les longues suites de chiffres copiées-collées sont exactes, mais les chiffres simples saisis à la main sont ceux qu’on rate
    • Désolé, cela va être corrigé
      Il a fallu rassembler les informations rapidement pour expliquer le problème, et oui, il y avait aussi un aspect marketing
      Donc quelques petites erreurs se sont glissées dedans, merci de les avoir signalées
    • Oui, dès que j’ai vu la formule « distributions directement vérifiées : RHEL 14.3 », la page de publication m’a au moins donné une impression d’AI slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      Et une fois arrivé au « Talk to our security experts » en bas de page, je me suis même demandé si ce fameux expert sécurité ne s’appelait pas Claude

  • Sur RHEL 9/10, algif_aead n’était pas un module mais un builtin, donc impossible à décharger
    J’ai donc cherché une solution de repli pour bloquer AF_ALG via systemd, avec un drop-in nécessaire pour chaque service exposé
    Il y a aussi un playbook Ansible qui couvre en général les cas importants comme sshd et user@
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • Sur RHEL 9/10, il était aussi possible d’ajouter initcall_blacklist=algif_aead_init aux options de démarrage du noyau puis de redémarrer
      Après cela, l’exploit ne fonctionnait plus
    • J’avais pensé à quelque chose de similaire, mais devoir bloquer ça service par service ressemble à un jeu de taupe
      Je m’inquiète des autres chemins d’exécution comme cronjob ou slurmjob, et j’aimerais qu’il existe un moyen de faire hériter ça globalement à tous les processus au niveau systemd, au lieu de devoir le définir service par service

  • Cet exploit semble fonctionner en remplaçant un binaire SUID pour le faire s’exécuter avec le PID 0
    Pourtant, le site affirme qu’il permet aussi de s’échapper de clusters Kubernetes / de conteneurs et de CI runners & build farms, mais je ne vois aucune explication concrète à l’appui pour l’évasion de conteneur, ni surtout de user namespace
    Je l’ai essayé dans Podman rootless et, comme prévu, il n’a pas permis de sortir du conteneur
    Le site affirme aussi « rendre root toutes les distributions Linux sorties depuis 2017 », mais les tests réels n’en couvrent que quatre, et cela n’a pas fonctionné sur Alpine

    • Le site a aussi indiqué qu’une explication détaillée allait bientôt être publiée, donc il y aura sans doute des étapes supplémentaires ou des correctifs dans une partie 2
      L’annonce dit : "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • Cette vulnérabilité permet d’écraser des octets en mémoire de fichiers lisibles, donc on peut assez facilement imaginer des possibilités d’évasion dans divers environnements
    • L’affirmation sur toutes les distributions depuis 2017 semble fondée sur le fait que cette vulnérabilité a été introduite par un commit de la seconde moitié de 2017
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      Cela dit, l’exploitabilité réelle dépendra du fait qu’il s’agisse d’une version majeure récente ou d’un noyau de maintenance sur une branche plus ancienne
    • Cet article nuit lui-même pas mal à sa propre crédibilité
      Cela dit, j’ai exécuté le PoC moi-même sur une instance 24.04 et la vulnérabilité semble bien réelle, avec un impact qui paraît important
      Mais le nombre de distributions touchées semble bien plus faible que ce qui est affirmé, et assez éloigné de la formule toutes les distributions depuis 2017
      Par exemple, si je comprends bien, Ubuntu 16.04 en fin de vie est légèrement touché, et le gros de l’impact semble plutôt concerner des noyaux vendor récemment déployés comme linux-gcp et linux-oracle-6.7, donc la famille 6.17
    • Même dans un conteneur rootless, s’il est possible de monter jusqu’au vrai UID 0, l’évasion peut ensuite devenir possible
      Mais cela demande des étapes supplémentaires, et Alpine peut lui aussi être vulnérable au fond, avec simplement un script à ajuster
      En fin de compte, ce n’est pas un exploit universel prêt à l’emploi, mais un PoC

  • La page elle-même a un côté un peu vibecoded et publicitaire, mais la vulnérabilité est réelle et sa gravité semble élevée
    Cela explique pourquoi une grosse mise à jour de sécurité est tombée aujourd’hui, donc je vais remonter sa priorité

    • C’est effectivement une pub assez flagrante, mais personnellement je trouve que c’est plutôt une bonne pub
      Ils trouvent de vrais bugs, les font corriger, apportent ainsi une contribution significative à l’écosystème OSS, et en profitent pour vendre leur outil de sécurité
    • Ces gens-là semblent déjà avoir assez de travail même sans publicité
      Mais en même temps, qui code encore ses pages web entièrement à la main aujourd’hui, surtout parmi des développeurs kernel ?