CVE-2026-31431 (Copy Fail) : ce que cela implique pour les appareils Linux embarqués – et les mesures à prendre dès maintenant

Le 29 avril 2026, Theori a révélé la faille CVE-2026-31431 (« Copy Fail ») – une vulnérabilité permettant l'escalade de privilèges dans le noyau Linux algif_aead interface cryptographique, accessible via des sockets AF_ALG. Cette faille touche les principales distributions Linux utilisant des versions du noyau vulnérables introduites en 2017.

Cette faille nécessite un accès local, mais son comportement déterministe et sa capacité à contourner les mécanismes de contrôle de l'intégrité des fichiers en font une menace pertinente pour les systèmes embarqués, en particulier ceux qui utilisent des conteneurs ou des versions Linux à usage général.

Cet article explique en quoi cette situation est particulière, où se situent les véritables risques pour les équipementiers du secteur de l'électronique embarquée, et comment y faire face.

En bref

• Type : Élévation des privilèges locaux (LPE)
• CVE : CVE-2026-31431 (CVSS 7,8)
• Conséquences : Les noyaux Linux à partir de 2017 avec CONFIG_CRYPTO_USER_API_AEAD activé
• Vulnérabilité : déterministe, sans condition de concurrence, preuve de concept publique disponible (script Python de 732 octets ; la primitive du noyau est indépendante du langage)
• Portée : entre conteneurs via le cache de pages partagé
• Correction : correctif du noyau disponible dans la branche stable et dans les backports des fournisseurs

En quoi « Copy Fail » est-il différent ?

Le noyau Linux a déjà connu des failles de sécurité très médiatisées permettant une élévation de privilèges. La faille « Dirty Cow » (2016) nécessitait une condition de concurrence et provoquait souvent des plantages. La faille « Dirty Pipe » (2022) concernait une version spécifique. La faille « Copy Fail » est d'un autre ordre.

C'est un processus déterministe. Il n'y a pas de course à gagner, pas de fenêtre temporelle, pas de décalages spécifiques au noyau. Le même exploit, sans aucune modification, permet d'obtenir les privilèges root sur Ubuntu, Amazon Linux, RHEL et SUSE – sur toutes les distributions grand public testées, sans nécessiter de conditions de synchronisation ni de conditions de concurrence. Cela élimine l'un des principaux mécanismes de défense naturels contre l'exploitation du noyau : l'imprévisibilité.

Il est invisible pour les outils d'intégrité classiques. L'exploit modifie le cache de pages en mémoire d'un binaire setuid, et non le fichier sur le disque. Les systèmes standard de surveillance de l'intégrité des fichiers, qui vérifient les sommes de contrôle au niveau du disque, ne détecteront rien. Le binaire sur le disque reste intact. Mais lorsque le noyau le charge, c'est la version corrompue en mémoire qui s'exécute – avec les privilèges root.

Et cela dépasse les limites des conteneurs. Le cache de pages est partagé entre tous les processus d'un hôte, y compris les conteneurs. Un conteneur compromis peut corrompre des fichiers binaires accessibles aux autres conteneurs et au noyau de l'hôte. Pour les architectures reposant sur l'isolation par conteneurs – notamment les conceptions à criticité mixte utilisées dans les systèmes médicaux et industriels –, cela constitue une voie d'évasion concrète hors du conteneur.

La cause technique profonde

La vulnérabilité se trouve dans le noyau algif_aead module cryptographique. Le problème provient d'une gestion non sécurisée des listes de dispersion (scatterlists) basées sur le cache de pages lors d'opérations AEAD sur place, ce qui permet d'obtenir des références en écriture vers des pages normalement en lecture seule et basées sur des fichiers. Une modification d'optimisation datant de 2017 a introduit cette gestion des opérations sur place, remettant ainsi en cause une hypothèse de sécurité fondamentale.

L'exploit exploite successivement les failles du noyau AF_ALG une interface cryptographique (qui permet aux utilisateurs sans privilèges d'effectuer un chiffrement accéléré par le matériel) avec splice() (qui transmet les pages du cache par référence plutôt que de les copier). Il en résulte une écriture contrôlée de 4 octets dans le cache de n'importe quel fichier accessible en lecture. Ciblez un binaire setuid approprié tel que /usr/bin/su et vous obtenez les droits d'administrateur.

AF_ALG est activé dans pratiquement toutes les configurations courantes du noyau. Aucun privilège particulier ni module supplémentaire n'est requis.

Où le risque est réel et où il ne l'est pas

« Copy Fail » est une faille permettant l'escalade de privilèges locaux. L'attaquant doit déjà disposer d'un accès local en tant qu'utilisateur sans privilèges.

Pour la plupart des appareils embarqués – instruments médicaux à usage unique, contrôleurs industriels, systèmes verrouillés –, il n'existe pas de compte utilisateur sans privilèges, pas de shell interactif, et aucun moyen d'exécuter un script Python sans avoir d'abord franchi un périmètre de sécurité distinct. Dans ces déploiements, la vulnérabilité directe est faible.

Les systèmes appliquant des politiques SELinux ou AppArmor strictes peuvent également présenter une vulnérabilité réduite. Sur les appareils Android/AOSP où SELinux est correctement mis en œuvre, l'interface de socket AF_ALG n'est généralement pas accessible aux processus non privilégiés – la divulgation de Theori a confirmé que les appareils bénéficiant d'une intégration poussée de SELinux ne sont pas affectés par cette faille. Cela vaut pour tout système embarqué – qu'il soit basé sur Android ou non – où des politiques de contrôle d'accès obligatoire restreignent l'accès aux interfaces cryptographiques du noyau.

Cela ne veut pas dire que vous pouvez l'ignorer. Trois scénarios sont à prendre en compte :

Architectures basées sur des conteneurs. Si votre appareil exécute plusieurs charges de travail dans des conteneurs sur un noyau partagé – une configuration de plus en plus courante dans les dispositifs médicaux qui regroupent des fonctions héritées sur des SoC modernes –, Copy Fail rompt le modèle d'isolation. Un conteneur d'application compromis peut s'échapper vers l'hôte.

Une vulnérabilité en chaîne. Une erreur de copie prend une tournure grave lorsqu'elle est associée à une faille permettant l'exécution de code à distance. Un attaquant qui obtient un accès initial via un bug dans une interface Web, une API exposée ou un canal de mise à jour compromis peut alors accéder instantanément aux privilèges root. C'est la chaîne qui fait toute la différence.

Conformité réglementaire. Même si la vulnérabilité n'est pas exploitable dans votre configuration, l'existence d'un CVE public accompagné d'une preuve de concept fonctionnelle entraîne des obligations en matière de documentation et d'évaluation en vertu des directives post-commercialisation de la FDA, du RDM de l'UE et de la norme CEI 62443. Vos équipes chargées de la qualité et de la conformité réglementaire doivent évaluer et consigner votre exposition à ce risque. Cette étape n'est pas facultative.

Ce n'est pas une question de distribution. C'est une question de configuration du noyau.

On croit souvent à tort qu'il s'agit d'un « problème de distribution » – et que passer d'Ubuntu à Yocto permettrait de l'éviter. Ce n'est pas tout à fait le cas. CVE-2026-31431 est un bogue du noyau. Toute version compilée à partir de versions vulnérables du noyau (introduites en 2017) contient le code affecté, qu'elle ait été assemblée par Canonical, Red Hat ou votre propre pipeline Yocto.

Mais cette vulnérabilité n'a d'importance que si CONFIG_CRYPTO_USER_API_AEAD est activé. C'est ce module qui expose AF_ALG à l'espace utilisateur et rend l'exploit accessible.

Les distributions polyvalentes – Ubuntu, RHEL, Debian, SUSE – l'activent par défaut. Elles n'ont pas le choix. Elles répondent à un large éventail de cas d'utilisation et ne peuvent pas prédire les besoins de l'utilisateur final. Elles fournissent tout, y compris la surface d'attaque.

Yocto et Buildroot, qu'ils utilisent des configurations de noyau par défaut ou étendues, se trouvent dans la même situation. Une compilation Yocto n'est pas automatiquement plus sûre qu'Ubuntu. Tout dépend des choix effectués lors de la configuration.

Un noyau embarqué correctement sécurisé – dans lequel chaque module est justifié au regard des besoins réels de l'appareil – ne permet probablement pas CONFIG_CRYPTO_USER_API_AEAD. Il n'y a aucune raison pour qu'un écran chirurgical ou un contrôleur industriel ait besoin d'un accès en espace utilisateur aux sockets cryptographiques du noyau. Le même raisonnement s'applique aux binaires setuid et aux comptes utilisateurs non privilégiés : dans une configuration minimale, aucun de ces éléments ne devrait exister. (Remarque : la preuve de concept publiée utilise Python, mais la primitive sous-jacente du noyau peut être déclenchée à partir de n'importe quel binaire compilé. L'absence de Python ne constitue pas à elle seule une mesure d'atténuation suffisante.)

La vulnérabilité se situe au niveau du noyau. La possibilité d'exploitation dépend des choix effectués lors de la configuration du système d'exploitation. Les fabricants d'équipements d'origine (OEM) qui ont délibérément opté pour une configuration du noyau tenant compte des aspects de sécurité ont peut-être réduit leur exposition, selon leur configuration spécifique. Ceux qui ont fourni une distribution standard – ou une version Yocto avec les paramètres par défaut – devraient vérifier leur configuration.

Pourquoi cela n'arrête pas de se produire

« Copy Fail » n'est pas la première faille CVE critique du noyau, et ce ne sera pas la dernière. Dirty Cow remonte à 2016. Dirty Pipe date de 2022. Le schéma se répète tous les quelques années, et le défi à relever reste toujours le même : évaluer l'impact, créer une image corrigée, la valider, la déployer sur les appareils sur le terrain, et tout documenter pour les autorités de régulation. Les outils qui ont permis de détecter Copy Fail – l'analyse de code assistée par IA – en trouveront d'autres. Le rythme des découvertes est sur le point de s'accélérer.

Il y a deux choses qu'il convient de dire clairement :

Le correctif n'est pas le plus difficile. C'est le déploiement qui l'est. Ubuntu et RHEL ont corrigé cette faille en quelques jours. Mais pour les appareils embarqués utilisés dans les hôpitaux, les usines et les véhicules, l'application de ce correctif nécessite une infrastructure OTA, une visibilité sur le parc, un contrôle des modifications réglementaires et une revalidation. De nombreux équipementiers qui s'appuient sur des distributions à usage général ne disposent pas de ce processus. Et l'exécution apt-get update sur un dispositif soumis à une réglementation entraîne une série de modifications de paquets non contrôlées, sans traçabilité, sans tests par rapport à votre application et sans possibilité de retour en arrière. Dans un environnement réglementé, cela ne constitue pas une mesure corrective, mais un manquement à la conformité.

Attention aux outils. Ce ne sont pas eux qui décident. Les scanners CVE et les outils SBOM signaleront les erreurs de copie en quelques heures. Mais ils ne déterminent pas si CONFIG_CRYPTO_USER_API_AEAD est même activée dans votre configuration. Elles ne vérifient pas si la vulnérabilité est exploitable sur un appareil ne comportant aucun utilisateur sans privilèges. Elles ne fournissent pas l'évaluation d'impact spécifique à l'appareil, la décision de correction ni les preuves de contrôle des modifications requises par votre dossier technique. C'est dans le fossé entre une alerte du tableau de bord et une correction validée et documentée que la plupart des fabricants perdent du temps.

Ces deux problèmes trouvent leur origine dans la même cause profonde : considérer le système d'exploitation comme un choix d'intégration ponctuel plutôt que comme une dépendance gérée dont le cycle de vie s'étend sur plusieurs années. Un noyau minimaliste, qui n'activerait que les fonctionnalités dont l'appareil a besoin, n'aurait pas exposé algif_aead avant tout. Un plan de mise à jour bien défini et un engagement de maintenance à long terme permettraient de combler le retard de déploiement lorsque le prochain CVE sera publié.

Mesures recommandées pour les équipementiers

Si vous développez ou assurez la maintenance de produits embarqués sous Linux, voici ce que nous vous recommandons.

1. Vérifiez d'abord la configuration de votre noyau. Avant de supposer que vous êtes vulnérable, vérifiez si CONFIG_CRYPTO_USER_API_AEAD est activée :

zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API_AEAD

Si /proc/config.gz n'est pas disponible sur votre cible (ce qui est courant dans les versions embarquées minimalistes) ; vérifiez plutôt votre système de compilation : consultez le .config ou defconfig dans votre arborescence des sources du noyau, exécutez grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) sur les distributions qui l'enregistrent à cet emplacement, ou dans Yocto, vérifiez directement le fichier defconfig de votre recette de noyau.

Si le résultat est not set ou s'il n'est pas présent, la chaîne d'exploitation connue n'est pas accessible sur votre appareil. Il s'agit d'une étape cruciale du triage initial.

2. Faites l'inventaire des versions de votre noyau. Identifiez les noyaux utilisés sur l'ensemble de vos gammes de produits et de votre parc informatique. Les versions de noyau datant de 2017 et des années suivantes qui intègrent le chemin d'exécution vulnérable et sur lesquelles le module est activé sont concernées.

3. Appliquez le correctif en amont. Passez à des versions du noyau qui intègrent ce correctif. Les versions corrigées sont disponibles dans la branche stable de Linux et via des rétroportages spécifiques aux fournisseurs.

4. Prenez des mesures d'atténuation avant d'appliquer un correctif. Si vous ne pouvez pas mettre à jour le noyau immédiatement, désactivez le algif_aead module, restreindre l'accès au socket AF_ALG à l'aide de seccomp, et appliquer des politiques SELinux ou AppArmor afin de limiter les processus autorisés à accéder à l'interface du socket cryptographique.

5. Réévaluez les hypothèses relatives à l'isolation des conteneurs. Si votre architecture utilise des conteneurs pour isoler les charges de travail sur un noyau partagé, cette vulnérabilité démontre clairement qu'il ne faut pas se fier uniquement aux conteneurs comme frontière de sécurité. Déterminez si votre modèle de menace nécessite une couche d'isolation matérielle ou au niveau de l'hyperviseur.

6. Mettez à jour votre nomenclature logicielle (SBOM) et vos registres de vulnérabilités. Intégrez la vulnérabilité CVE-2026-31431 dans votre nomenclature logicielle et vos évaluations des risques de cybersécurité. Pour les dispositifs réglementés par la FDA, cela doit être pris en compte dans votre plan de gestion de la cybersécurité post-commercialisation. Dans le cadre du RDM de l'UE, cela peut donner lieu à une évaluation de vigilance.

7. Planifiez votre mise à jour sur le terrain. Pour les appareils déjà déployés, déterminez votre stratégie de mise à jour. Si vous disposez d'une mise à jour OTA, privilégiez cette option. Si ce n'est pas le cas, c'est le moment de réfléchir à la manière dont vous allez gérer la prochaine faille CVE critique du noyau – car il y en aura une.

8. Communiquez avec vos clients. Informez vos clients en aval et les utilisateurs cliniques de cette vulnérabilité, de votre évaluation et de votre calendrier. La transparence renforce la confiance.

Le signal plus large

Une dernière chose à noter. La faille « Copy Fail » a été découverte grâce à une révision du code assistée par l'IA. Un chercheur a utilisé un outil d'analyse automatisé sur le sous-système cryptographique du noyau, et celui-ci a identifié la faille en environ une heure. Un bug logique qui était resté invisible pendant neuf ans.

La donne est en train de changer pour les équipementiers du secteur de l'électronique embarquée. Le rythme auquel des vulnérabilités graves du noyau sont découvertes va s'accélérer. La question n'est pas de savoir si votre système d'exploitation comporte des vulnérabilités – c'est le cas. La question est de savoir si votre processus d'ingénierie, votre infrastructure de mise à jour et votre documentation réglementaire sont capables de suivre le rythme.

Avertissement : Le présent article est fourni à titre purement informatif et ne constitue en aucun cas un conseil juridique, réglementaire ou en matière de cybersécurité. Les informations qu'il contient reflètent des observations générales concernant une vulnérabilité rendue publique et peuvent ne pas s'appliquer à certaines configurations d'appareils ou à certains environnements de déploiement. Il incombe aux clients et aux fabricants d'équipements d'origine (OEM) d'évaluer l'applicabilité, l'impact et les mesures correctives au sein de leurs propres systèmes, y compris la conformité aux exigences réglementaires applicables. L4B Software ne garantit pas que les informations fournies soient exhaustives ou suffisantes pour une utilisation particulière.