DirtyClone (CVE-2026-43503): nouvelle faille Linux locale dans la famille DirtyFrag

Dans le cadre de notre veille sécurité, nous signalons DirtyClone, suivie sous l’identifiant CVE-2026-43503.

Le sujet est sérieux, mais il faut le lire correctement: DirtyClone n’est pas une faille distante qui permettrait, seule, de prendre le contrôle d’un serveur exposé sur Internet. C’est une élévation de privilèges locale Linux. Elle devient critique dès qu’un attaquant dispose déjà d’un point d’appui sur l’hôte: compte utilisateur, shell applicatif, conteneur trop permissif, job CI malveillant, poste développeur compromis ou bastion partagé.

DirtyClone appartient à la même famille que Copy Fail, DirtyFrag et Fragnesia: des chemins noyau optimisés manipulent des pages mémoire, des fragments réseau et du page cache. Quand un marqueur de sécurité se perd en route, une optimisation de performance peut devenir une primitive d’écriture dans de la mémoire associée à des fichiers.

Ce qui change avec DirtyClone

JFrog Security Research explique avoir identifié une variante résiduelle malgré les correctifs déjà apportés à la famille DirtyFrag. Le problème se situe dans des chemins de traitement de paquets du noyau Linux, notamment autour des sk_buff et de la propagation du marqueur SKBFL_SHARED_FRAG.

Dit simplement: le noyau doit savoir quand un fragment réseau pointe vers une page partagée, potentiellement issue du cache d’un fichier. Ce marquage permet d’éviter qu’un traitement réseau, par exemple une opération de chiffrement ou déchiffrement en place, écrive directement dans une page qui ne devrait pas être modifiée.

DirtyClone montre qu’un chemin de duplication ou de transfert de fragments peut perdre cette information. À partir de là, un buffer adossé au page cache peut être traité comme s’il était un simple buffer réseau modifiable.

L’impact décrit par JFrog est une élévation locale vers root. The Hacker News résume le scénario offensif: un attaquant peut viser un binaire privilégié en mémoire, provoquer une modification de sa copie en page cache, puis bénéficier de cette version modifiée à l’exécution. Le fichier sur disque peut rester intact, ce qui complique les contrôles d’intégrité basés uniquement sur les hashes disque.

Pourquoi une faille locale reste urgente

Il est tentant de minimiser une LPE parce que “l’attaquant doit déjà être local”. Sur une infrastructure moderne, ce raisonnement est trop confortable.

Du code local non totalement maîtrisé existe partout:

• runners CI/CD;
• plateformes de build;
• conteneurs;
• noeuds Kubernetes;
• sandboxes;
• postes développeurs;
• bastions;
• environnements multi-utilisateurs;
• services qui exécutent des scripts, plugins ou traitements fournis par des tiers.

Dans ces contextes, la question n’est pas seulement “comment l’attaquant entre ?”. La vraie question est: que peut-il devenir après un premier accès limité ?

Une LPE noyau transforme parfois un incident applicatif en compromission complète de l’hôte. C’est pour cela que DirtyClone doit être traitée dans le même plan d’action que les autres failles de la famille DirtyFrag.

Le lien avec Copy Fail, DirtyFrag et Fragnesia

Nos articles précédents permettaient déjà de suivre cette chaîne.

Avec Copy Fail, le sujet portait sur une écriture inattendue dans le page cache via des chemins liés à AF_ALG, splice() et au module algif_aead.

Avec DirtyFrag, le problème s’est déplacé vers des chemins réseau comme XFRM/ESP et RxRPC. La mitigation temporaire consistait notamment à bloquer esp4, esp6 et rxrpc, si ces modules n’étaient pas nécessaires.

Avec Fragnesia, la famille a encore évolué: un autre chemin XFRM/ESP pouvait perdre l’information indiquant qu’un fragment était partagé.

DirtyClone prolonge la même leçon. Les correctifs doivent couvrir tous les chemins qui déplacent ou dupliquent des fragments partagés. Un patch qui corrige un chemin précis ne suffit pas si un autre helper laisse tomber le même marqueur.

Quels fixes précédents restent utiles ?

Il faut distinguer mitigation, correctif partiel et correction durable.

La mitigation Copy Fail algif_aead

Elle reste pertinente pour réduire l’exposition à Copy Fail si vous êtes encore dans ce cas précis.

Mais elle ne protège pas contre DirtyFrag, Fragnesia ou DirtyClone. DirtyClone passe par d’autres chemins du noyau. Un serveur sur lequel algif_aead est désactivé ne doit donc pas être considéré comme protégé contre CVE-2026-43503.

Le blocage esp4, esp6, rxrpc

Cette mitigation reste utile comme mesure compensatoire dans la famille DirtyFrag, à condition qu’elle ne casse pas d’usages légitimes comme IPsec/ESP ou certains environnements spécifiques.

Mais elle n’est pas une garantie complète. JFrog et Penligent rappellent que les workarounds réduisent la surface, tandis que la vraie réponse reste le noyau corrigé. De plus, si ces fonctionnalités sont compilées directement dans le noyau ou si l’exploitation emprunte une variante non couverte par votre blocage, la mitigation peut être insuffisante.

La restriction des namespaces non privilégiés

Limiter les user namespaces non privilégiés peut empêcher certains utilisateurs locaux d’obtenir facilement CAP_NET_ADMIN dans un namespace réseau, condition utile pour plusieurs scénarios DirtyClone.

Mais là encore, ce n’est pas un correctif. Cela peut réduire l’exposition sur Debian, Fedora ou d’autres environnements où les namespaces sont ouverts, mais cela peut aussi casser des usages légitimes: conteneurs rootless, navigateurs, sandboxes, outils développeurs ou CI.

La bonne approche est ciblée: durcir les hôtes exposés à du code non fiable, sans casser aveuglément tout un parc.

Les correctifs DirtyFrag et Fragnesia isolés

Ils sont nécessaires, mais pas forcément suffisants.

JFrog indique qu’un système n’est correctement protégé contre ce modèle d’exploitation qu’une fois la série complète de correctifs appliquée: les premiers correctifs DirtyFrag, le correctif Fragnesia, puis les correctifs de suivi associés à CVE-2026-43503.

La conclusion opérationnelle est simple: il ne suffit pas de dire “nous avons patché DirtyFrag”. Il faut vérifier si votre distribution a intégré les correctifs DirtyClone dans le noyau réellement chargé.

Systèmes à prioriser

DirtyClone doit être traitée en priorité sur les environnements où l’exécution locale non totalement maîtrisée est normale ou plausible.

À regarder en premier:

• runners CI/CD et serveurs de build;
• noeuds Kubernetes;
• hôtes Docker ou plateformes de conteneurs;
• environnements multi-tenant;
• bastions et jump boxes;
• postes développeurs;
• serveurs applicatifs pouvant donner un shell après compromission;
• plateformes SaaS exécutant du code utilisateur;
• machines avec namespaces non privilégiés ouverts;
• hôtes où des conteneurs disposent de privilèges réseau larges.

Pour Kubernetes, il faut insister sur un point: reconstruire une image de conteneur ne patche pas le noyau du noeud. DirtyClone concerne le host kernel. La remédiation se traite donc côté worker node: mise à jour du noyau, redémarrage, livepatch si disponible, ou remplacement des noeuds.

Vérifier sans exécuter de PoC dangereux

Penligent insiste sur un point que nous partageons: un PoC DirtyClone ne doit pas devenir une procédure de validation en production.

Un exploit public cherche à prouver l’impact, pas à produire une preuve d’audit propre. Sur cette famille de bugs, il peut volontairement déclencher une corruption du page cache. Le bon résultat attendu n’est pas “avons-nous obtenu root ?”, mais:

1. le noyau réellement chargé contient-il le correctif ?
2. un utilisateur non privilégié peut-il atteindre les capacités ou namespaces nécessaires ?
3. les modules et surfaces concernés sont-ils accessibles ?
4. existe-t-il des traces suffisantes pour surveiller une tentative ?

Commandes de vérification non destructives:

uname -r

lsmod | grep -E '^(esp4|esp6|rxrpc)\b' || true

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces 2>/dev/null || true

Sur Debian/Ubuntu, complétez avec l’état des paquets noyau:

dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

Sur les distributions RPM:

rpm -qa | grep -E '^kernel|^kernel-core' | sort

Ces commandes ne prouvent pas à elles seules que tout est corrigé. Elles donnent les éléments à comparer aux bulletins de votre distribution.

Mitigation temporaire si le patch ne peut pas partir tout de suite

La réponse durable reste l’installation d’un noyau corrigé, puis le redémarrage effectif sur ce noyau. En attendant, plusieurs mesures peuvent réduire l’exposition selon le profil de l’hôte.

Restreindre les namespaces non privilégiés

Sur certains systèmes, désactiver les user namespaces non privilégiés réduit la capacité d’un utilisateur local à obtenir des capacités réseau dans un namespace.

Exemple à valider avant déploiement:

sysctl -w kernel.unprivileged_userns_clone=0

Cette mesure peut casser des workloads. Elle doit être testée avant application large, surtout sur postes développeurs, CI, navigateurs, sandboxes et conteneurs rootless.

Bloquer les modules DirtyFrag si inutiles

Si IPsec/ESP et RxRPC ne sont pas utilisés, le blocage des modules déjà évoqué dans DirtyFrag peut rester une mesure compensatoire.

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyclone.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Attention: esp4 et esp6 peuvent être nécessaires à IPsec. rxrpc peut être utile dans des environnements spécifiques. Pousser cette mitigation sans qualification peut créer un incident réseau.

Patcher, redémarrer, prouver

La correction opérationnelle doit aller jusqu’au noyau réellement exécuté.

Le piège classique sur Linux est de croire qu’un paquet installé suffit. Ce n’est pas vrai pour une faille noyau. Tant que la machine n’a pas redémarré sur le noyau corrigé, ou tant qu’un livepatch n’est pas vérifié comme actif, l’ancien noyau peut rester en production.

La séquence saine:

1. inventaire des hôtes Linux;
2. priorisation des systèmes CI, conteneurs, multi-utilisateurs et bastions;
3. vérification du noyau chargé;
4. comparaison avec les advisories de la distribution;
5. mitigation temporaire si nécessaire;
6. installation du noyau corrigé;
7. redémarrage ou vérification livepatch;
8. contrôle post-maintenance;
9. conservation des preuves: version, heure de reboot, bulletin, résultat de vérification.

Si une exploitation est suspectée, ne vous contentez pas d’un hash disque propre. Cette famille de bugs peut modifier la copie en page cache sans modifier immédiatement le fichier sur disque. Il faut traiter l’hôte comme potentiellement compromis: processus, credentials, persistance, secrets, mouvements latéraux.

Notre lecture opérationnelle

DirtyClone confirme que la série Copy Fail, DirtyFrag et Fragnesia n’était pas un accident isolé.

On est face à une famille de problèmes où les optimisations du noyau Linux, notamment le zero-copy réseau et les transformations en place, doivent conserver une information de provenance mémoire de bout en bout. Quand cette information est perdue, le page cache devient une frontière de sécurité fragilisée.

Chez Forget About IT, ce type d’alerte entre dans une réponse structurée:

• veille CVE;
• qualification de l’exposition réelle;
• priorisation des hôtes à risque;
• mitigation temporaire si elle est compatible;
• patch management;
• redémarrage contrôlé;
• vérification du noyau réellement chargé;
• conservation de preuves d’intervention.

La réponse doit être rapide, mais elle ne doit pas être aveugle. Désactiver IPsec sur un hôte qui en dépend peut provoquer une panne. Ne rien faire sur un runner CI exposé à du code non fiable peut laisser une voie d’escalade très concrète.

Conclusion

DirtyClone (CVE-2026-43503) est une nouvelle faille locale Linux de la famille DirtyFrag. Elle ne remplace pas les alertes précédentes: elle montre que la correction doit couvrir toute la chaîne des fragments partagés.

Le bon réflexe:

• ne pas considérer la mitigation Copy Fail comme suffisante;
• ne pas considérer un patch DirtyFrag isolé comme une garantie;
• prioriser les hôtes CI/CD, conteneurs, Kubernetes, multi-utilisateurs et bastions;
• éviter les PoC en production;
• vérifier le noyau réellement chargé;
• patcher et redémarrer dès que possible.

Si vous avez besoin d’aide pour qualifier l’exposition ou organiser la remédiation sur vos serveurs Linux, nous pouvons vous accompagner dans le cadre de notre infogérance.

• Lire notre article sur DirtyFrag
• Lire notre article sur Fragnesia CVE-2026-46300
• Lire notre article sur Copy Fail CVE-2026-31431
• Découvrir notre infogérance Linux
• Nous contacter

Sources

• JFrog Security Research - Dissecting and Exploiting Linux LPE Variant: DirtyClone (CVE-2026-43503)
• The Hacker News - New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets
• Penligent - CVE-2026-43503 PoC, DirtyClone and Safe Linux Exposure Verification

FAQ: DirtyClone et CVE-2026-43503

Qu’est-ce que DirtyClone, ou CVE-2026-43503 ?

DirtyClone est une vulnérabilité locale du noyau Linux, suivie sous CVE-2026-43503, qui appartient à la famille DirtyFrag et peut permettre une élévation de privilèges vers root via une corruption du page cache.

DirtyClone est-elle exploitable à distance ?

Non. Les sources publiques la décrivent comme une élévation de privilèges locale: l’attaquant doit déjà pouvoir exécuter du code sur l’hôte ou dans un environnement local comme un runner CI, un conteneur ou une machine partagée.

Les mitigations Copy Fail ou DirtyFrag suffisent-elles contre DirtyClone ?

Non. Désactiver algif_aead ne couvre pas DirtyClone, et les mitigations esp4, esp6, rxrpc ou namespaces réduisent seulement certaines conditions d’exploitation. La protection durable reste le noyau corrigé avec la série complète de correctifs.

Faut-il exécuter un PoC DirtyClone en production pour tester ?

Non. Un PoC DirtyClone cherche à déclencher une corruption du page cache et une élévation de privilèges. En production, il faut privilégier les vérifications non destructives: version du noyau chargé, état des paquets, advisories distribution, namespaces, modules et politiques de capacités.

Quels systèmes prioriser pour CVE-2026-43503 ?

Les priorités sont les runners CI/CD, hôtes multi-utilisateurs, noeuds Kubernetes, plateformes de conteneurs, bastions, postes développeurs et tout système où du code non totalement maîtrisé peut s’exécuter localement.