Pourquoi l'exploit « Copy Fail » est différent des précédentes failles du noyau Linux

Accédez directement au résumé généré par l'IA de cet article de blog

En bref

De quoi s'agit-il ? D'une faille de sécurité sous Linux permettant l'escalade de privilèges en local, baptisée « Copy Fail » (CVE-2026-31431). Il s'agit d'une faille logique dans le chemin AEAD de l'authentification du noyau, accessible depuis l'espace utilisateur via l'interface de socket AF_ALG et la fonction splice(2).

Impact : une preuve de concept de 732 octets, déjà publiée, permet de faire passer de manière fiable un utilisateur local sans privilèges au niveau root sur les principales distributions Linux équipées de noyaux vulnérables.

Statut : des noyaux corrigés sont désormais disponibles via AlmaLinux, Ubuntu et d'autres distributions dérivées. La CISA a ajouté le CVE-2026-31431 à son catalogue des vulnérabilités connues pour lesquelles des exploits existent, le 1er mai. CVSS 7,8 (HIGH).

Gravité : vecteur local, aucun privilège requis, aucune intervention de l'utilisateur, exploitation hautement fiable. Dans de nombreux environnements conteneurisés ou à exécution partagée, une exploitation réussie depuis l'intérieur d'un conteneur pourrait entraîner la compromission de l'hôte.

Agissez dès maintenant : protégez immédiatement les noyaux concernés. Les organisations utilisant la correction en direct sans redémarrage peuvent neutraliser la voie d'exploitation sans attendre les fenêtres de maintenance ou les redémarrages. Sinon, déployez les noyaux corrigés par le fournisseur dès que cela est opérationnellement possible. Si aucune de ces deux options n'est immédiatement envisageable, désactivez temporairement la voie AF_ALG AEAD vulnérable en suivant les consignes d'atténuation ci-dessous.

Copy Fail est préoccupant car il réunit trois caractéristiques que les défenseurs redoutent de voir coexister : une large diffusion, une exploitation extrêmement fiable et la publication d'une preuve de concept le jour même de la divulgation.

Suis-je concerné ?

C'est presque certain, à moins que vous n'ayez déjà installé le correctif.

La faille « Copy Fail » touche les versions de Linux en amont à partir du noyau 4.14, ce qui signifie que presque toutes les distributions d'entreprise activement maintenues ont hérité de ce chemin de code vulnérable :

Versions d'Ubuntu antérieures à Resolute (26.04)
Red Hat Enterprise Linux 8, 9 et 10
AlmaLinux 8, 9, 10 et Kitten 10
Les équivalents de Rocky Linux, CentOS Stream et Oracle Linux
Fedora (version actuelle et versions récentes)
Debian stable et testing
openSUSE Tumbleweed et Leap
La plupart des versions dérivées, y compris les variantes de CloudLinux

Le principal sujet de préoccupation concerne les équipements qui ne font pas partie des parcs d'entreprise faisant l'objet d'une maintenance active : les appareils Linux embarqués, les noyaux OEM dans les équipements réseau, les systèmes industriels et les déploiements en fin de vie qui risquent de ne jamais recevoir de correctif. Si un appareil n'a pas reçu de mises à jour du noyau de la part du fournisseur récemment, il faut partir du principe qu'il pourrait rester exposé de manière permanente.

La vulnérabilité dépend de la disponibilité de l'interface algif_aead dans le noyau, qui est configurée de l'une ou l'autre des deux manières selon la distribution.

Vérification rapide :


# Check if loaded as a module (Debian, Ubuntu, Arch-family)

lsmod | grep '^algif_aead '

# Check if built into the kernel (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Une sortie vide de la commande `lsmod` n'est pas le signe de sécurité qu'elle semble être. Sur Debian, Ubuntu et les distributions de la famille Arch, `algif_aead` se charge automatiquement à la demande : un processus sans privilèges peut déclencher ce chargement simplement en ouvrant un socket AF_ALG avec un nom d'algorithme correspondant. Sur les distributions de la famille RHEL, le code est compilé directement dans le noyau (CONFIG_CRYPTO_USER_API_AEAD=y) et n'apparaît jamais dans lsmod, quel que soit l'état. Considérez l'hôte comme exposé, sauf si la ligne de commande du noyau met explicitement l'initcall AEAD sur liste noire ou si le noyau a été patché.

Le simple fait que votre distribution renforce la sécurité des espaces de noms utilisateur ne vous protège pas pour autant. Le déclencheur « Copy Fail » ne nécessite pas la création d'un nouvel espace de noms : la famille de sockets AF_ALG est accessible directement depuis un processus standard sans privilèges dans les installations par défaut.

Qu'est-ce qu'un « copy fail » ?

Copy Fail est une faille de sécurité permettant l'élévation des privilèges locaux dans le sous-système de cryptographie du noyau Linux. Ce bogue réside dans le modèle AEAD « authencesn » – le mode de chiffrement authentifié utilisé pour l'ESN IPsec – et peut être exploité lorsqu'il est atteint via AF_ALG en combinaison avec la fonction splice(2).

Cette combinaison exploitable est le résultat de trois modifications apportées à plusieurs années d'intervalle, dont aucune n'était en soi problématique. Le modèle « authencesn », ajouté en 2011 pour gérer les numéros de séquence étendus IPsec ESP, utilisait le tampon de destination de l'appelant comme espace de travail – ce qui était inoffensif tant que seule la couche xfrm interne du noyau l'appelait. AF_ALG a ensuite exposé les opérations AEAD à l'espace utilisateur. En 2017, une optimisation des performances a supprimé une copie interne dans le chemin AEAD, permettant au noyau d'opérer directement sur la page mémoire fournie. Cette combinaison est devenue dangereuse lorsque le chemin de données provenait de splice(2) contre une page du cache de pages adossée à un fichier.

La découverte elle-même explique en partie pourquoi ce bug est important. Taeyang Lee, chercheur chez Theori, a émis l'hypothèse que la combinaison des sockets AF_ALG avec la fonction splice(2) pourrait créer une surface d'attaque peu explorée autour de la provenance des pages de la liste de dispersion. Plutôt que de procéder à un audit manuel, l'équipe a intégré cette hypothèse d'une ligne dans Xint Code – son système d'analyse assisté par IA – en ciblant le répertoire crypto/. Environ une heure plus tard, Copy Fail est apparu comme le résultat présentant le niveau de gravité le plus élevé. D'autres failles de gravité élevée détectées lors de ce même scan font toujours l'objet d'une divulgation coordonnée.

La correction en amont consiste en une annulation directe du commit d'optimisation initial (a664bf3d603d). Ce détail est important car il montre comment ces bogues échappent souvent à la révision : l'optimisation en elle-même semblait correcte prise isolément, mais les chemins d'exécution adjacents n'ont jamais été modélisés par rapport à celle-ci.

Pourquoi Copy Fail est différent

C'est le point auquel il faut prêter attention si vous avez suivi le flot incessant de vulnérabilités de type LPE sous Linux au cours de la dernière décennie : Dirty COW, Dirty Pipe, StackRot, Dirty Frag et d'autres de la même famille.

Dirty Pipe a eu un impact significatif car il a permis de transformer la corruption du cache de pages en une technique pratique d'escalade de privilèges. La plupart des failles de cette catégorie présentaient toutefois encore des obstacles opérationnels. Elles étaient soumises à des conditions de concurrence, spécifiques à une version du noyau, dépendantes de modules inhabituels, bloquées par des restrictions d'espace de noms, ou suffisamment peu fiables pour que les défenseurs puissent, dans la pratique, gagner du temps.

Copy Fail élimine en grande partie ces obstacles.

Selon les informations disponibles, l'exploit publié fonctionnerait avec peu ou pas de modifications sur les principales distributions Linux grand public testées par les chercheurs. Il ne comporte pas de longue table de décalage spécifique à chaque distribution ni de logique complexe de sélection de cibles. Le chemin d'exploitation est exceptionnellement portable.

La fenêtre d'exposition est également exceptionnellement large. L'optimisation vulnérable a été intégrée dans la version en amont de Linux en 2017 et s'est propagée aux noyaux à support à long terme qui sont encore couverts par les programmes de support des éditeurs aujourd'hui. Cela inclut les systèmes d'entreprise, les déploiements embarqués, les appliances et les infrastructures figées dont les organisations reportent souvent la mise à niveau pendant des années.

Mais surtout, l'exploitation est extrêmement fiable. De nombreuses LPE modernes au niveau du noyau impliquent un comportement probabiliste : mise en forme du tas, chronométrage des conditions de concurrence ou chaînes complexes impliquant plusieurs primitives. Copy Fail est en comparaison relativement simple. Les tentatives aboutissent ou échouent de manière nette, sans déstabiliser l'hôte.

La surface d'attaque accessible est également d'une fréquence inhabituelle. Contrairement aux modules de niche impliqués dans certaines failles récentes du noyau, algif_aead est largement présent dans les distributions courantes et est soit compilé par défaut, soit chargé automatiquement à la demande. Les installations par défaut sur les serveurs, les ordinateurs de bureau et les hôtes de conteneurs exposent souvent un chemin d'accès depuis un processus sans privilèges vers le code vulnérable.

Il en résulte que bon nombre des hypothèses traditionnelles visant à « gagner du temps » ne sont pas d'une grande utilité dans ce cas précis. En pratique, pour réduire significativement les risques, il faut soit appliquer un correctif au noyau, soit supprimer l'accès à la voie d'exploitation.

Pourquoi les infrastructures modernes aggravent la situation

Le terme « attaquant local » désignait autrefois une situation relativement limitée : un accès physique, des identifiants SSH volés ou une compromission préalable du réseau.

Cette définition ne reflète plus le fonctionnement des infrastructures Linux en 2026.

Les infrastructures modernes reposent sur l'exécution partagée. Les nœuds Kubernetes hébergent conjointement des charges de travail provenant de différents espaces de noms. Les exécuteurs CI/CD exécutent le code issu des pull requests de contributeurs externes. Les notebooks cloud, les environnements de test pour développeurs, les plateformes SaaS multi-locataires et les systèmes de compilation exécutent couramment du code partiellement fiable sur des noyaux partagés.

Dans ce contexte, le terme « local » tend de plus en plus à recouvrir ce que l'on entendait autrefois par « connecté à Internet ».

Une dépendance npm malveillante détectée lors de l'intégration continue (CI), une faille RCE dans une application web permettant d'obtenir un shell à privilèges limités, un compte développeur compromis ou une chaîne d'évasion de conteneur incomplète peuvent tous servir de tremplin vers un accès root complet. Copy Fail réduit considérablement la distance entre le point d'ancrage initial et la compromission totale au niveau du noyau.

Cette vulnérabilité ne peut pas être exploitée à distance en soi. Un attaquant a toujours besoin de pouvoir exécuter du code quelque part sur l'hôte. Cependant, dans les environnements d'exécution partagée, les points d'ancrage potentiels sont déjà suffisamment nombreux pour que cette distinction ait moins d'importance qu'auparavant.

Comment fonctionne réellement cette faille

Linux met les fonctionnalités cryptographiques du noyau à la disposition de l'espace utilisateur via les sockets AF_ALG. Un processus peut demander des algorithmes tels que authencesn(hmac(sha256),cbc(aes)) et transmettre des données via des interfaces de lecture/écriture standard.

L'optimisation de 2017 visait à améliorer les performances en évitant les copies internes superflues lors de certaines opérations AEAD. Au lieu de copier les données d'entrée dans des tampons temporaires puis d'en recopier les résultats, le noyau pouvait parfois opérer directement sur la page mémoire fournie.

Cette hypothèse ne tient plus lorsque les données proviennent, via la fonction `splice(2)`, d'un descripteur associé à un fichier. Contrairement aux opérations de lecture et d'écriture classiques, `splice` peut transférer des références à des pages déjà mises en cache au lieu de copier les données. Le module de cryptage a considéré à tort ces pages comme de l'espace de travail inscriptible et a effectué une transformation sur place sur celles-ci.

Ce comportement est propre à authencesn. Les autres algorithmes AEAD standard – GCM, CCM, authenc classique – limitent leurs écritures à la zone de sortie légitime. Le modèle authencesn, initialement écrit pour un chemin de code IPsec interne qui contrôlait les deux extrémités de l'opération, traite la liste de diffusion de destination de l'appelant comme un espace de travail temporaire. Lorsque AF_ALG a exposé ce chemin à l'espace utilisateur et que splice y a injecté des pages adossées à des fichiers, il en a résulté une primitive qui écrit 4 octets contrôlés par opération dans le cache de pages de n'importe quel fichier lisible.

En réalité, chaque opération échoue : la vérification HMAC échoue car le texte chiffré est fictif, et la fonction recvmsg() renvoie une erreur à l'appelant. L'écriture de 4 octets est néanmoins effectuée. En répétant l'opération à différents décalages, un attaquant parvient à injecter du shellcode dans l'image mise en cache d'un binaire setuid tel que /usr/bin/su.

Le contenu du disque ne change jamais. La modification n'existe qu'en mémoire jusqu'à ce que la page mise en cache soit évacuée. Les outils de vérification de l'intégrité du système de fichiers, le hachage des fichiers et l'analyse forensique du disque peuvent donc ne rien détecter d'anormal, même si l'image exécutable mise en cache a été altérée suffisamment longtemps pour permettre à l'attaquant de l'exécuter en tant qu'administrateur.

La chaîne de preuve de concept publique est relativement courte :

Ouvrir un socket AF_ALG lié à authencesn
Ouvrir un binaire setuid tel que /usr/bin/su en mode lecture
Utilisez la commande « splice » pour déplacer les pages mises en cache de la cible vers le chemin AF_ALG
Lance l'opération de chiffrement en place, qui écrit 4 octets choisis par l'attaquant à chaque appel
Répéter l'opération sur tous les décalages pour implanter le shellcode dans l'image mise en cache
Exécutez le fichier binaire mis en cache et modifié en tant qu'administrateur

Des réimplémentations en C, Go et sur arm64 existent déjà parallèlement au PoC Python d'origine. Le fait que la version de Python sur la cible soit plus ancienne ne constitue pas un obstacle majeur. Le document technique original de Xint/Theori reste la meilleure référence technique pour les défenseurs qui ont besoin de détails plus approfondis sur l'implémentation.

Atténuation

La solution la plus sûre consiste à protéger immédiatement le noyau en cours d'exécution. Il existe trois moyens concrets de réduire l'exposition, classés ici par ordre de rapidité et d'impact opérationnel.

1. Application des correctifs sans redémarrage (méthode la plus rapide, sans interruption de service)

KernelCare a publié des correctifs en direct pour corriger la faille « Copy Fail » sur les noyaux d'entreprise pris en charge et en cours d'exécution, avant même que plusieurs distributions en aval ne proposent des versions mises à jour des paquets du noyau.

Ce correctif sans redémarrage neutralise la faille de sécurité sur le noyau en cours d'exécution sans nécessiter de redémarrage immédiat, ce qui permet de réduire immédiatement la vulnérabilité plutôt que d'attendre le prochain cycle de maintenance.

Certains scanners de vulnérabilité peuvent continuer temporairement à signaler des versions du noyau affectées, même après l'application d'un correctif sans redémarrage, car les versions des paquets fournies par les éditeurs et la logique de détection des scanners peuvent ne pas être à jour par rapport à l'état actuel du noyau en exécution.

Pour les organisations qui gèrent des infrastructures où la disponibilité est cruciale, c'est le moyen le plus rapide de remédier au problème.

Vous n'êtes pas encore client de KernelCare ? Les nouveaux clients bénéficient d'une réduction jusqu'à la fin du mois de juin. Pour en savoir plus sur KernelCare, cliquez ici.

2. Installez un noyau corrigé et redémarrez

La procédure standard de correction consiste à déployer le paquet de noyau corrigé fourni par le fournisseur, puis à redémarrer les systèmes concernés.

Les organisations doivent vérifier la disponibilité des correctifs pour leur distribution et donner la priorité aux environnements dans lesquels du code partiellement fiable peut s'exécuter, notamment les nœuds Kubernetes, les exécuteurs CI/CD, les serveurs partagés, l'infrastructure des développeurs et les plateformes d'applications multi-locataires.

3. Mesures correctives manuelles temporaires (si l'application du correctif doit attendre)

Si ni la correction à chaud ni les fenêtres de redémarrage immédiat ne sont disponibles, la surface d'attaque AF_ALG AEAD peut être temporairement désactivée via la ligne de commande du noyau.

À lire en premier : les mesures correctives ci-dessous éliminent la surface d'attaque AF_ALG AEAD. La plupart des charges de travail fonctionnent sans problème : dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS et SSH n'en dépendent pas. Les applications utilisant explicitement le moteur OpenSSL afalg, le déchargement cryptographique matériel via AF_ALG ou la liaison directe de sockets AEAD peuvent échouer ou subir une perte de performances. Vérifiez avant tout déploiement à grande échelle.

Commencez par vérifier comment algif_aead est intégré à votre noyau :

# Loadable module (Debian, Ubuntu, Arch family)

grep -qE '^algif_aead ' /proc/modules && echo "loaded as module" || echo "not currently loaded"

# Built-in (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Si la commande `config grep` renvoie « y », le code est intégré au noyau. Les commandes `modprobe blacklists` et `rmmod` sembleront s'exécuter sans message d'erreur, mais n'offriront aucune protection.

Solution universelle (fonctionne aussi bien avec les noyaux modulaires qu'avec les noyaux intégrés) – désactivez la fonction initcall via la ligne de commande du noyau :

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

sudo reboot

Après le redémarrage, vérifiez :

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline

Si la sortie est vide, cela signifie que le paramètre n'a pas été pris en compte : vérifiez à nouveau grubby et assurez-vous qu'un véritable redémarrage a bien eu lieu.

Mesure d'atténuation réservée aux modules chargeables (Debian, Ubuntu, Arch et autres distributions similaires) – utile lorsqu'il faut reporter le redémarrage :

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif_aead.conf'

sudo rmmod algif_aead 2>/dev/null || true

Confirmer :

grep -qE '^algif_aead ' /proc/modules && echo "still loaded" || echo "not loaded"

Ne vous fiez pas à cette méthode sur les serveurs de la famille RHEL. Ces deux commandes renvoient un résultat positif, que le système soit intégré ou non, ce qui donne un faux sentiment de sécurité.

En cas de suspicion d'exploitation, videz le cache afin que les pages exécutables modifiées soient rechargées depuis le disque :

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Il s'agit ici de confinement, et non de remédiation. Si un pirate a déjà obtenu un accès root, des mécanismes de persistance peuvent déjà exister ailleurs sur le système.

SELinux et AppArmor peuvent techniquement bloquer la création de sockets AF_ALG, mais uniquement s’ils sont configurés pour l’interdire aux processus non confinés ou bénéficiant d’autorisations trop larges. Les politiques par défaut de toutes les principales distributions l’autorisent. Considérez les restrictions basées sur le MAC comme une mesure de renforcement de la sécurité pour les déploiements à l’échelle du parc informatique, et non comme une solution d’urgence à mettre en œuvre le jour même.

Pour les opérateurs Kubernetes, OVHcloud a publié une stratégie d'atténuation basée sur les DaemonSets pour les clusters gérés. Ce modèle peut s'appliquer de manière générale à tous les environnements Kubernetes où il est difficile de coordonner les redémarrages pendant les fenêtres d'intervention d'urgence.

Si AF_ALG ne peut pas être désactivé car certaines charges de travail en dépendent, les options restantes consistent à isoler les exécutions locales non fiables ou à appliquer des correctifs au noyau sans redémarrage jusqu’à ce que des fenêtres de maintenance soient disponibles.

Pour les utilisateurs de KernelCare Enterprise, des correctifs sans redémarrage pour le problème « Copy Fail » ont été publiés pour les noyaux d'entreprise pris en charge existants avant que plusieurs distributions en aval ne publient des versions mises à jour de leurs paquets de noyau.

Par conséquent, certains scanners pourraient continuer temporairement à signaler des versions vulnérables du noyau, même lorsque le noyau en cours d'exécution a déjà été protégé grâce à l'application de correctifs sans redémarrage. Des versions mises à jour du noyau fournies par les éditeurs, ainsi qu'une logique de détection adaptée, devraient suivre.

Détection

Il n'existe aucune signature fiable permettant de détecter une compromission a posteriori pour Copy Fail.

Une exploitation réussie ne laisse aucune trace sur le disque, le schéma des appels système ressemble à une activité cryptographique légitime dans l'espace utilisateur, et les modifications mises en cache disparaissent dès que les pages sont libérées.

Dans la plupart des environnements, il sera difficile de confirmer rétrospectivement l'incident, à moins que la télémétrie des appels système, l'instrumentation eBPF ou la journalisation détaillée des audits n'aient déjà été activées avant que l'exploitation ne se produise.

Parmi les signaux les plus utiles à surveiller, on peut citer :

Le module algif_aead se charge de manière inattendue sur les systèmes ne comportant aucun consommateur AF_ALG connu
Exécution inhabituelle de « su » ou « sudo » peu après une activité AF_ALG
Opérations `splice(2)` ciblant des sockets AF_ALG à partir de descripteurs liés à des fichiers

Les règles de détection basées sur les schémas d'exécution Python ne permettront pas de détecter d'autres implémentations : des réimplémentations de l'exploit en C, Go et sur arm64 sont accessibles au public et ne nécessitent pas la présence de Python sur la machine cible. Il s'agit là d'approches heuristiques, et non de garanties. Tout système sur lequel des utilisateurs non autorisés ont eu accès à un shell pendant la période d'exposition doit être considéré comme potentiellement compromis.

Liste de contrôle des mesures correctives prioritaires

Appliquez un correctif ne nécessitant pas de redémarrage ou déployez immédiatement un noyau corrigé. Les utilisateurs de KernelCare Enterprise peuvent neutraliser la faille sur les noyaux pris en charge en cours d'exécution sans redémarrer. Sinon, installez le paquet de noyau corrigé par le fournisseur et redémarrez les systèmes concernés.
Si l'application du correctif doit être reportée, appliquez la mesure de mitigation consistant à ajouter « initcall_blacklist=algif_aead_init » à la ligne de commande du noyau après avoir évalué l'impact sur la charge de travail. La solution de contournement basée sur « modprobe », mentionnée dans certaines alertes initiales, ne fonctionne pas sur les noyaux de la famille RHEL.
Passez en revue les environnements dans lesquels du code partiellement fiable peut s'exécuter : systèmes d'intégration continue (CI), hébergements mutualisés, nœuds Kubernetes, infrastructures de développement et parcs de machines de travail SaaS.
Recherchez toute activité suspecte liée à AF_ALG à compter de la divulgation du 29 avril.
Redémarrez les systèmes sur lesquels les correctifs ont été installés afin d'effacer l'état d'exécution vulnérable et les pages mises en cache.

Pourquoi ce type d'erreur revient sans cesse

Les problèmes « Copy Fail », « Dirty Pipe » et « Dirty Frag » diffèrent par leurs détails de mise en œuvre, mais partagent le même schéma sous-jacent : des chemins rapides axés sur les performances qui reposent sur des hypothèses erronées concernant la propriété de la mémoire.

Dans chaque cas, une opération d'écriture a concerné une page que le noyau considérait à tort comme pouvant être modifiée sans risque.

Le cache de pages est régulièrement compromis, car il est partagé de manière intentionnelle. Chaque processus qui lit un fichier accède à la même page physique sous-jacente. Une seule écriture involontaire sur cette page partagée peut devenir visible pour les binaires privilégiés qui chargent du code exécutable à partir de celle-ci.

La solution ne consiste pas simplement à « cesser d'optimiser ». Les systèmes modernes reposent sur ces optimisations de performances. De même, désactiver définitivement le module qui se trouve être impliqué dans la dernière faille de sécurité n'est pas une solution viable à long terme.

La solution à long terme consiste à renforcer les garanties de propriété des pages dans l'ensemble des mécanismes de gestion de la mémoire du noyau – un travail que les responsables du projet en amont ont déjà entamé, mais qui avance lentement car il touche certains des sous-systèmes du noyau les plus sensibles aux performances.

« Copy Fail » ne sera probablement pas la dernière faille de ce type.

Et Linux ne représente peut-être que la partie visible du problème.

La faille « Copy Fail » a survécu près d’une décennie au sein d’un code open source soumis à des révisions approfondies, avant d’être détectée en une heure environ par un scanner assisté par IA, à la suite d’une simple instruction de l’opérateur. Linux est la partie de la pile qui est analysée parce qu’elle peut l’être – ouvertement, par n’importe qui. La surface bien plus vaste des micrologiciels propriétaires, des noyaux de fournisseurs, des protocoles hérités et des microcodes de puces reposait historiquement sur l’hypothèse selon laquelle un code caché signifiait des bogues cachés. Comme l’affirme Igor Seletskiy dans « Open Source is the Tip of the Iceberg », cette hypothèse est désormais en train de disparaître. Copy Fail est l’un des premiers exemples ; ce ne sera pas l’un des derniers.