DirtyClone et le bug du marqueur « Shared-Frag » qui ne cesse de réapparaître

En bref

Aller directement à la version longue ↓

Quoi : DirtyClone, répertorié sous le nom de 43503, est une faille d'élévation de privilèges locaux dans le noyau Linux, au niveau de la pile réseau : certains chemins de transfert de fragments SKB ignorent le SKBFL_SHARED_FRAG marqueur qui bloque les écritures sur place, permettant ainsi au flux entrant ESP (IPsec) d’être déchiffré directement sur les pages du cache de pages adossées à des fichiers. Il s’agit d’une écriture arbitraire dans des fichiers en lecture seule appartenant à l’utilisateur root, une attaque « Dirty COW » via la pile réseau plutôt que /proc/self/mem.

Conséquences : Un utilisateur local sans privilèges transforme la perte de marqueur en une écriture dans le cache de page sur un fichier binaire tel que /usr/bin/su, puis exploite cette image corrompue pour accéder au répertoire racine. JFrog a publié un guide d'exploitation le 25 juin ; le PoC public (rafaeldtinoco/security/exploits/dirtyclone, s'appuyant sur la primitive DirtyFrag de Hyunwoo Kim) fonctionne sur les anciens noyaux. Le fichier sur le disque ne change jamais, ce qui fait que les outils de vérification de l'intégrité des fichiers ne le détectent pas.

Statut : DirtyClone appartient à la famille DirtyFrag/Fragnesia : un marqueur de sécurité est perdu lorsque la mémoire adossée à un fichier transite par des chemins réseau à haut débit, et une écriture sur place effectuée ultérieurement atterrit à l’endroit où elle aurait dû être copiée. JFrog l'a signalé le 19 mai ; le correctif a été intégré à la version v7.1-rc5 le 24 mai. Il s'agit donc d'une vulnérabilité de type « N-day » pour les parcs RHEL ne disposant pas de l'intégralité de la chaîne de correctifs, et non d'une nouvelle vulnérabilité de type « 0-day ».

Gravité : Red Hat la classe comme « importante » (CVSS 7.0) ; kernel.org lui attribue une note de 8,8, en raison d’une complexité d’attaque jugée faible et d’une évaluation de la portée « modifiée » (par opposition à « inchangée »), mais dans les deux cas, l’issue est l’accès aux privilèges root. Catégorie de bogue : une défaillance de propagation d’un marqueur de fragment partagé entraînant des écritures non sécurisées sur place dans la mémoire gérée par le cache de pages.

Pourquoi est-ce important ? : Les systèmes exposés sont ceux dont le produit est l'isolation : les hôtes multi-locataires, les exécuteurs d'intégration continue (CI), les nœuds de conteneurs et de Kubernetes, ainsi que les environnements de test accessibles via CAP_NET_ADMIN, que de nombreuses distributions accordent par défaut aux utilisateurs sans privilèges au sein d'un espace de noms. Dans ce contexte, « local » ne signifie pas « faible risque ».

Faites-le tout de suite : Le correctif est déjà disponible dans les flux EL9 et EL10 ; veuillez donc effectuer la mise à jour et redémarrer. Si vous ne pouvez pas encore appliquer le correctif, désactivez les espaces de noms des utilisateurs sans privilèges ou bloquez esp4/esp6 chargement automatique lorsque le protocole IPsec n'est pas utilisé. KernelCare Les utilisateurs disposent déjà d'un correctif ne nécessitant pas de redémarrage pour les noyaux EL9/EL10 concernés. Vous trouverez plus de détails ci-dessous.

Certaines des failles les plus graves du noyau Linux ne se présentent pas au départ comme une vulnérabilité évidente de type « écriture dans les fichiers racine ». Elles trouvent leur origine dans des erreurs de gestion interne. DirtyClone en fait partie. L'absence d'un indicateur de propriété sur des fragments de tampon de socket est considérée comme valide par une opération réseau ultérieure, qui effectue alors une écriture directe.

La pile réseau Linux achemine les paquets de données dans des tampons de socket, ou « skbs ». Une partie de ces données est stockée sous forme de fragments de page plutôt que d’être copiée octet par octet dans la mémoire privée. Cela est bénéfique pour les performances, mais ne laisse aucune marge d’erreur en matière de propriété, car un fragment peut pointer vers une page partagée, appartenant à une entité externe ou gérée par le cache de pages. Avant qu’un code n’écrive dans une telle page, il doit s’assurer qu’il est possible de la modifier en toute sécurité.

C'est là toute la mission de SKBFL_SHARED_FRAG. Ce marqueur indique au code chargé du traitement ultérieur des paquets qu’un SKB contient des fragments partagés et que toute modification in situ est interdite, à moins que le noyau ne copie d’abord les données dans la mémoire privée. Un « DirtyClone » se produit lorsque ce marqueur disparaît lors du transfert de fragments d’un SKB à un autre. Noms NVD __pskb_copy_fclone() et skb_shift() parmi les mécanismes permettant de déplacer des descripteurs de fragments sans transférer le marqueur, laissant le SKB de destination avec des références adossées au cache de pages tandis que skb_has_shared_frag() renvoie « false ».

Cette réponse erronée constitue la vulnérabilité. Un programme d’écriture sur place exécuté ultérieurement examine le skb, vérifie si les fragments sont partagés, obtient une réponse négative, puis écrit directement dans la page sous-jacente. L’entrée ESP dans esp4.c C'est exactement ce genre d'auteur, et c'est là que mène cette exploitation par le public.

DirtyClone vient compléter une série de bogues apparus au cours du printemps, présentant tous le même mode de défaillance. La mémoire du cache de pages, qui s'appuie sur des fichiers, est traitée comme des données de paquets ordinaires, puis une opération réseau in situ écrit à l'endroit où elle aurait dû copier. Copy Fail est apparu en premier fin avril. DirtyFrag a suivi le 7 mai. Fragnesia a contourné le correctif de DirtyFrag le 13 mai. DirtyClone est le quatrième, accessible via un autre chemin de clonage de paquets qui supprime le même marqueur d'un bit.

Voici l'élément qui devrait vous aider à évaluer la gravité de la situation. DirtyClone n’est pas une nouvelle faille « 0-day » qui affecte des parcs informatiques entièrement mis à jour. Ce que JFrog a publié le 25 juin montre que des chemins de code résiduels laissés ouverts par un correctif partiel restent accessibles. Le mot clé ici est « complet ». Un noyau n’est protégé que s’il intègre l’intégralité de la chaîne DirtyFrag et Fragnesia. Un noyau qui a appliqué le correctif initial pour DirtyFrag mais qui n’a pas installé les mises à jour suivantes présente toujours un chemin accessible vers le même récepteur ESP. Les noyaux EL9 et EL10 actuels de Red Hat intègrent déjà le backport complet, c’est pourquoi le danger concerne les noyaux qui ont quelques mises à jour de retard plutôt que les versions actuelles.

Comment fonctionne DirtyClone ?

La chaîne publique va d'une configuration de socket sans privilèges à une écriture arbitraire dans le cache de pages privilégié.

[Unprivileged user + network namespace]
│  attacker obtains CAP_NET_ADMIN inside the namespace
▼
[netfilter TEE rule clones ESP-in-UDP packets]
│  clone routed through __pskb_copy_fclone(), marker dropped
▼
[Mislabelled skb: references page-cache pages,
reports skb_has_shared_frag() == false]
▼
[XFRM ESP transport SA decrypts in place]
│  esp_input() AES-CBC writes over the target file's page cache
▼
[Arbitrary content in root-owned page cache]
│  overwrite /usr/bin/su (or /etc/sudoers.d/* via an NSS load)
▼
[uid=0 root shell]

Le marqueur. Le noyau marque tout skb contenant des références à des pages qui ne lui appartiennent pas avec SKBFL_SHARED_FRAG, et skb_has_shared_frag() lit cette balise pour déterminer si une charge utile peut être modifiée in situ. Lorsqu’un assistant de transfert de fragments déplace des fragments paginés d’un SKB à un autre sans transférer le marqueur, le SKB de destination conserve les références aux pages gérées en externe ou stockées dans le cache de pages, tout en indiquant qu’aucun élément n’est partagé.

L'évier. Un programme d'écriture sur place ultérieur se fie à ce rapport. Dans le cas de DirtyClone, le programme d'écriture est esp_input() Le déchiffrement AES-CBC, qui déchiffre directement ces pages, y compris le cache des fichiers en lecture seule appartenant à l'utilisateur root. En contrôlant la clé ESP et l'association de sécurité, ainsi que les pages source intercalées, l'attaquant parvient à écrire un contenu arbitraire dans le cache des pages privilégiées.

L'itinéraire. Red Hat attribue l'exposition aux versions EL9 et EL10 à skb_try_coalesce() la perte du marqueur (Bugzilla 2480902), et signale que cette perte peut également se produire dans toute une famille de fonctions d'aide, notamment __pskb_copy_fclone(), skb_shift(), skb_gro_receive(), et skb_segment(). Le PoC public accède au même récepteur ESP par une autre voie. Il s'exécute au sein d'un espace de noms utilisateur et réseau sans privilèges, et installe une règle netfilter TEE qui clone les paquets ESP-in-UDP via __pskb_copy_fclone(), qui supprime le marqueur, puis installe des SA de transport XFRM ESP afin que le paquet cloné et mal étiqueté soit déchiffré directement dans le cache de pages du fichier cible.

L'important, c'est qu'il ne s'agit pas d'une modification /usr/bin/su sur le disque au sens habituel du terme. Elle corrompt la copie du cache de pages en mémoire que le noyau fournit ensuite à une voie d’exécution privilégiée. C’est ce qui fait que la surveillance classique de l’intégrité des fichiers constitue ici un contrôle peu efficace. Le fichier sur le disque reste intact, la modification se trouve dans la copie en mémoire du noyau, et un redémarrage rétablit le binaire d’origine, généralement bien après que l’attaquant a déjà obtenu les privilèges root.

Un détail est important pour définir le périmètre d’impact. Le fichier README du PoC mentionne une plage étroite allant de la version v7.1-rc1 à la version rc4 de la branche principale, mais nos tests internes ont permis de reproduire le problème sans modification sur les noyaux rétroportés vers EL9 et EL10. Cette plage indiquée en amont ne limite pas l’impact sur les distributions de la famille RHEL. Ne vous fiez pas à la plage de versions indiquée dans le fichier README pour conclure que votre machine EL n’est pas concernée.

Ce que modifie le correctif « Upstream »

La correction est mineure, et c'est précisément pour cette raison que la famille continue de produire des variantes. Elle fait en sorte que les aides au transfert de fragments propagent le marqueur de fragment partagé, de sorte qu'un skb de destination qui fait encore référence à des pages gérées par le cache de pages ou appartenant à des entités externes signale skb_has_shared_frag() comme étant vrai. Le module d’écriture sur place (in-place writer) plus récent refuse alors de modifier ces pages et se rabat sur une copie sécurisée. Le correctif a été intégré en amont le 21 mai et intégré à Linux v7.1-rc5 le 24 mai, dans le cadre de la même série de correctifs qui a résolu les bugs « DirtyFrag » antérieurs. Les identifiants de commit pour les versions stables et les rétroportages varient selon les branches ; il est donc préférable de se référer à l’avis de sécurité de votre distribution plutôt qu’à un hash en amont spécifique.

Qui est concerné ?

Pour les utilisateurs lambda de Linux, il existe un risque si le noyau en cours d’exécution ne dispose pas de la chaîne complète de correctifs « DirtyFrag », « Fragnesia » et « DirtyClone » et si le système permet à du code local non fiable d’accéder aux fonctionnalités réseau requises par l’exploit. Des rapports publics identifient Debian, Fedora et Ubuntu parmi les distributions où les espaces de noms des utilisateurs non privilégiés facilitent l’exploitation dans des configurations courantes. Ubuntu 24.04 et les versions ultérieures intègrent des restrictions AppArmor susceptibles de bloquer la voie d’exploitation par défaut ; toutefois, il s’agit d’un renforcement de la sécurité sur un seul chemin d’accès, ce qui ne garantit pas que le noyau sous-jacent ait été corrigé.

Pour les systèmes de la famille RHEL, le tableau est plus restreint et se résume à deux questions : le noyau est-il concerné par les errata « DirtyFrag » et « Fragnesia », et l'hôte exécute-t-il un correctif sans redémarrage ?

Vulnérabilité exploitée, reproduite en interne sur des noyaux ne disposant pas de la chaîne complète :

• EL9 activé 5.14.0-611.49.2.el9_7, remplace /usr/bin/su et donne uid=0.
• EL10 activé 6.12.0-55.27.1.el10_0, même résultat.

Non vulnérable :

• Les noyaux de série actuels qui intègrent déjà le correctif complet pour DirtyFrag et Fragnesia, par exemple EL10 6.12.0-211.16.1.el10_2, où le PoC ne fonctionne pas.
• Tout hôte protégé par le correctif « rebootless » sur le esp4 module.

Non concerné par la vulnérabilité CVE-2026-43503 :

• RHEL 6, 7 et 8. Red Hat indique que ces versions ne sont pas concernées par ce CVE spécifique. Il convient d’interpréter cette affirmation au sens strict. Les listes de flux concernés varient selon les versions de la famille DirtyFrag ; ainsi, un flux considéré comme non concerné par le CVE-2026-43503 ne l’est pas nécessairement pour tous les CVE associés.

Red Hat répertorie RHEL 9 et RHEL 10, ainsi qu’OpenShift RHCOS, comme des branches concernées par la vulnérabilité CVE-2026-43503. Cela désigne la branche de code concernée, et non un hôte entièrement mis à jour. Il faut comprendre « concerné » comme signifiant « ce code a été intégré ici », et non « chaque machine RHEL 9 ou 10 actuelle est aujourd’hui vulnérable ».

Le calendrier de mise à jour varie également selon la distribution et la version du noyau. CloudLinux (CL8 et CL9), en particulier, peut accuser un retard par rapport aux flux EL pour cette famille ; les utilisateurs de CL doivent donc vérifier la version exacte qu’ils utilisent plutôt que de supposer une parité.

Une mise en garde qui s'applique à toute la famille. Un hôte qui ne répond tout simplement pas aux hypothèses du PoC n'est pas la même chose qu'un hôte corrigé. Vérifiez que le noyau intègre l'intégralité des errata, plutôt que de supposer qu'un échec de l'exécution de l'exploit signifie que vous êtes en sécurité.

Agir dès maintenant

La solution définitive consiste à appliquer un correctif au noyau ou à installer un correctif ne nécessitant pas de redémarrage. En attendant que cette solution soit généralisée, les mesures de protection les plus efficaces sont celles qui éliminent les conditions préalables à l'exploitation de la faille.

1. Appliquez d'abord un correctif ou un correctif ne nécessitant pas de redémarrage

Installez le noyau corrigé fourni par votre distribution et redémarrez le système, ou appliquez un correctif ne nécessitant pas de redémarrage si celui-ci n'est pas envisageable. Le correctif est déjà disponible dans les dépôts EL9 et EL10 ; sur la plupart des machines, il s'agit donc d'une simple mise à jour plutôt que d'une attente.

2. Limiter les espaces de noms des utilisateurs sans privilèges

La chaîne a besoin de CAP_NET_ADMIN aux utilisateurs sans privilèges pour installer la règle TEE et le SA XFRM. Si on supprime cela, le chemin public ne fonctionne plus.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

Rayon d'impact. Cela empêche le fonctionnement de Podman sans droits d'administrateur et de Docker sans droits d'administrateur, unshare(1), le bac à sable de Chromium, certains bacs à sable d’intégration continue (CI) et les Flatpaks bwrap. Acceptable sur la plupart des parcs de serveurs hautement sécurisés, mais perturbant sur les hôtes de conteneurs et les machines de développement. À tester avant un déploiement à grande échelle.

3. Empêcher le chargement automatique du module ESP lorsque IPsec n'est pas utilisé

Non esp4 ou esp6, aucun point de déchiffrement sur place n'est prévu pour le chemin DirtyClone.

echo -e 'install esp4 /bin/false\ninstall esp6 /bin/false' | sudo tee /etc/modprobe.d/dirtyclone-esp.conf

N'appliquez pas cette modification sur les hôtes qui utilisent IPsec ou XFRM, car elle désactive le transport ESP et interrompra vos tunnels. Remarque à l'attention de l'ensemble de la communauté : les travaux antérieurs sur DirtyFrag impliquaient également rxrpc en tant que récepteur d'écriture sur place, le renforcement de la sécurité contre l'ensemble de la famille peut donc impliquer de bloquer rxrpc également. Cette modification perturbe le fonctionnement d'AFS et d'autres charges de travail dépendantes de RxRPC ; veillez donc à la limiter avec précaution et à ne l'appliquer que là où ces fonctionnalités ne sont pas utilisées. Pour annuler cette modification, supprimez les fichiers de remplacement et rechargez le système.

sudo rm -f /etc/modprobe.d/dirtyclone-esp.conf /etc/sysctl.d/99-dirtyclone.conf
sudo sysctl --system

Prise de décision. Si l'hôte n'utilise ni IPsec ni conteneurs sans privilèges, les deux solutions sont envisageables et le blocage du module ESP constitue la modification la moins invasive. S'il a besoin d'IPsec mais pas de conteneurs sans privilèges, désactivez les utilisateurs non privilégiés. S'il a besoin à la fois d'IPsec et de conteneurs sans privilèges, un correctif sans redémarrage ou un noyau corrigé est la seule solution qui ne perturbe pas les charges de travail ; vous devriez isoler toute exécution locale non fiable jusqu'à ce que l'une de ces solutions soit mise en place.

Patching sans redémarrage

C'est précisément pour ce genre de bogues que des solutions de correction sans redémarrage, comme KernelCare, ont été conçues. Redémarrer tout un parc de serveurs avec un noyau corrigé est facile à dire mais difficile à organiser, et les correctifs sans interruption comblent cette lacune sans affecter la disponibilité du système.

Sur les noyaux EL9 et EL10 concernés, cela se produit au niveau du esp4 module et désactive le canal de décryptage des entrées ESP exactement au moment où l'écriture non sécurisée aurait lieu. Lorsque le marqueur de fragment partagé est absent en raison du bogue de propagation, le décryptage sur place des fragments stockés dans le cache de pages est refusé au lieu d'être effectué. Cette garantie est identique à celle offerte par le correctif du marqueur en amont, mais elle est mise en œuvre sans que personne n'ait à intervenir pendant une fenêtre de maintenance.

Étant donné que DirtyClone et CVE-2026-46300 partagent la même faille à l'origine et le même correctif, un seul correctif sans redémarrage permet de corriger les deux. Bon à savoir lorsque vous vérifiez la couverture : dans certains outils, la protection apparaît sous le CVE-2026-46300 plutôt que sous le CVE-2026-43503, car l'attribution du numéro CVE peut prendre du retard par rapport au correctif lui-même.

L'intérêt ici est limité mais bien réel, et c'est précisément là que réside l'atout des correctifs sans redémarrage. Les serveurs les plus exposés sont ceux qui ont pris du retard dans les mises à jour du noyau, et ce sont justement ceux pour lesquels il est le plus difficile de programmer un redémarrage d'urgence. La possibilité de corriger la faille « DirtyClone » sur ces serveurs sans ce redémarrage fait la différence entre une correction immédiate et une correction lors de la prochaine fenêtre de maintenance ; pour de nombreux parcs de serveurs, c'est dans cet intervalle que réside le véritable risque.

Détection

Il n'existe aucune signature fiable sur le disque pour DirtyClone, ce qui constitue un élément central du risque. La corruption se trouve dans le cache de pages ; le fichier binaire sur le disque reste intact, et l'éviction du cache ou un redémarrage rétablit les octets d'origine. Cela n'annule toutefois pas la persistance, les modifications de compte ou les activités ultérieures survenues après que l'attaquant a obtenu les privilèges root. Le hachage des fichiers constitue ici un contrôle peu efficace.

Cela ne laisse peut-être aucune trace évidente compromettant l'intégrité des fichiers, mais ce n'est pas pour autant invisible. La détection se fera probablement grâce à la télémétrie comportementale, et chacun des éléments suivants constitue davantage une piste qu'une preuve :

• Inattendu esp4 ou esp6 le module se charge sur les hôtes qui n'utilisent pas IPsec.
• Création d'un espace de noms utilisateur sans privilèges, suivie peu après par l'installation de XFRM SA ou l'insertion d'une règle TEE dans netfilter.
• Insolite nft, iptables, XFRM ou TEE provenant de contextes utilisateur locaux.
• Exécution d'un binaire setuid tel que su ou sudo immédiatement après cette configuration réseau, par un utilisateur qui n'avait aucune raison d'intervenir sur l'un ou l'autre.
• Une absence soudaine d'événements d'audit de sécurité attendus sur un hôte qui devrait les générer.

Si du code local non fiable ou partiellement fiable a été exécuté sur un hôte EL9 ou EL10 exposé pendant cette période, donnez la priorité à l'application des correctifs et considérez que cet hôte mérite un examen plus approfondi, plutôt que de conclure que l'absence de traces sur le disque signifie qu'il n'a pas été compromis.

Pourquoi celui-ci est important

DirtyClone ne permet pas l’exécution de code à distance, et cela ne signifie pas qu’un internaute non authentifié puisse prendre le contrôle d’un serveur Linux. Pour les environnements dans lesquels ce bug se manifeste réellement, cette distinction n’est guère rassurante. Les runners d’intégration continue (CI) exécutent le code d’autres personnes. Les plateformes d’hébergement mutualisé exécutent le code de leurs clients. Les nœuds Kubernetes exécutent des conteneurs présentant différents niveaux de confiance. Les environnements de test pour développeurs et les hôtes de compilation autorisent souvent précisément le comportement des espaces de noms qui rend cette classe accessible. Dans chacun de ces cas, c’est une élévation de privilèges locaux qui constitue l’événement déclencheur. Elle transforme un code qui s’exécutait là où il était autorisé en un code qui a acquis les privilèges root là où il n’aurait jamais dû.

La raison pour laquelle DirtyClone présente un niveau d’urgence inférieur à ce que laissent entendre les gros titres est également celle pour laquelle il est facile de se tromper. Un noyau intégrant la chaîne complète de DirtyFrag et Fragnesia est protégé. Mais « complet » est ici le mot clé. Un noyau qui a appliqué le correctif DirtyFrag d’origine puis n’a plus été mis à jour présente toujours une faille d’exploitation, tout comme n’importe quel hôte en retard sur les rétroportages de sa distribution. Le risque se concentre sur les machines qui ont manqué la dernière fenêtre de maintenance, les environnements de CI à longue durée de vie que personne ne redémarre, et les serveurs mis de côté pour le trimestre suivant. Ce sont précisément ces hôtes sur lesquels une faille de type « N-day » comme celle-ci devient discrètement un problème le jour même. Un workflow reposant uniquement sur un scanner, qui se base sur le flux de noyaux affectés sans vérifier la chaîne complète de correctifs, peut soit donner de fausses alertes sur des hôtes déjà corrigés, soit passer à côté de ceux qui restent exposés.

Liste de contrôle des mesures correctives prioritaires

1. Commencez par appliquer un correctif ou un correctif sans redémarrage aux systèmes EL9 et EL10 qui ont pris du retard dans les mises à jour du noyau, en particulier les hôtes de conteneurs, les environnements d'exécution CI, les systèmes partagés et les environnements multi-locataires.
2. Vérifiez que le noyau en cours d'exécution intègre bien l'ensemble des correctifs relatifs à DirtyFrag, Fragnesia et DirtyClone, plutôt que de conclure à l'absence de risque sur la base d'un échec lors de l'exécution d'un exploit.
3. Considérez qu'un correctif partiel de la faille « DirtyFrag » laisse la vulnérabilité intacte. Seule la chaîne complète permet de colmater la faille.
4. Lors de la vérification de la couverture du correctif « rebootless-patch », il est possible que la protection apparaisse sous le numéro CVE-2026-46300 dans certains outils, jusqu’à ce que le mappage vers CVE-2026-43503 soit effectif.
5. Les versions CL8 et CL9 de CloudLinux peuvent présenter un décalage par rapport aux flux EL de cette gamme ; veuillez donc vérifier votre version exacte.
6. Désactivez les espaces de noms d'utilisateurs sans privilèges lorsque la charge de travail le permet.
7. Bloc esp4 et esp6 le chargement automatique lorsque IPsec n'est pas utilisé, et rxrpc de même si vous mettez en place des mesures de sécurisation contre la famille élargie et que vous n'utilisez ni AFS ni RxRPC.
8. Recherche d'espaces de noms inhabituels : XFRM, ESP, TEE, nft, su, et sudo l'activité pendant la période d'exposition, et considérer les hachages de fichiers « propres » comme des preuves insuffisantes.

Appliquez des correctifs à tous les noyaux, sans redémarrage. Si vous n'utilisez pas encore KernelCare, c'est le moment idéal pour découvrir comment l'application de correctifs sans redémarrage protège les systèmes Linux critiques, sans nécessiter de fenêtres de maintenance d'urgence ni de temps d'arrêt.

Procurez-vous KernelCare dès aujourd’hui →

Références

• Red Hat CVE-2026-43503, Important, CVSS 7.0, RHEL 9 et 10 concernées, RHEL 6/7/8 non concernées ; Bugzilla 2480902
• Fichier JSON contenant les données de sécurité de Red Hat, CVE-2026-43503
• NVD CVE-2026-43503 (score CNA de kernel.org : 8,8, modification de la portée)
• Suivi de sécurité Debian, CVE-2026-43503
• Problème apparenté CVE-2026-46300 (Bugzilla 2477015), même cause première via skb_try_coalesce, explique comment y remédier
• JFrog Security Research, « Analyse et exploitation d'une variante de la vulnérabilité LPE sous Linux : DirtyClone (CVE-2026-43503) »
• SecurityWeek : une faille du noyau Linux « DirtyClone » permet d'obtenir un accès root
• The Hacker News : une nouvelle faille du noyau Linux baptisée « DirtyClone » permet aux utilisateurs locaux d'obtenir les privilèges root via des paquets clonés
• Preuve de concept publique, rafaeldtinoco/security/exploits/dirtyclone (JFrog ; primitive ESP « DirtyFrag » de Hyunwoo Kim)
• Correction intégrée dans la branche principale de Linux v7.1-rc5