La faille COW du programme « pedit » sous Linux à l'origine d'un nouvel exploit permettant d'obtenir les privilèges root

Vous cherchez des mesures d'atténuation ? Passez directement à la section suivante ↓

En bref

Description : une faille d’élévation de privilèges locaux sous Linux appelée « pedit COW » (CVE-2026-46331), due à une écriture sans vérification des limites dans l’action de contrôle du trafic « act_pedit » du noyau. La fonction tcf_pedit_act() calcule une seule fois sa plage de copie à l'écriture (copy-on-write) avant de modifier les en-têtes de paquets ; elle ne prend pas en compte le décalage d'exécution ajouté par les clés typées au moment de l'exécution, et finit par écrire dans une page qu'elle n'a jamais rendue privée – une opération COW partielle qui aboutit dans le cache de pages partagées.

Impact : une preuve de concept publique et vérifiée par l'auteur offre à tout utilisateur local non privilégié un moyen prêt à l'emploi d'accéder à un shell root sur les systèmes affectés où l'action `act_pedit` est accessible et où des espaces de noms d'utilisateurs non privilégiés sont disponibles. La preuve de concept corrompt l'image mise en cache du fichier `setuid-root /bin/su` et permet d'accéder directement au shell root. Red Hat classe cette vulnérabilité comme « importante ».

Statut : Il s’agit d’une faille de type « N-day », et non d’une surprise « same-day ». Le correctif a été développé en toute transparence sur la liste netdev sous la forme d’un correctif de routine visant à corriger une corruption de données (objet : « net/sched : correction d’un COW partiel dans pedit entraînant une corruption du cache de pages »), sans numéro CVE ni présentation sous l’angle de la sécurité. Le CNA de kernel.org a attribué le numéro CVE-2026-46331 au moment de la fusion, le 16 juin 2026 – plusieurs semaines après que les détails permettant l’exploitation aient déjà été rendus publics – et un PoC exploitable a été publié le 17 juin. Les branches « mainline » et « stable » ont été corrigées ; Red Hat et AlmaLinux ont publié des errata.

Gravité : vecteur d'attaque local, faible complexité une fois les conditions préalables réunies, aucune interaction de l'utilisateur, corruption déterministe du cache de page permettant l'accès aux droits root, et code d'exploitation public fonctionnel. Catégorie de vulnérabilité : écriture hors limites entraînant une corruption de mémoire et une élévation locale des privilèges. Le score CVSS n'était pas encore définitif au moment de la publication ; la note « Important » attribuée par Red Hat constitue la référence à prendre en compte pour agir.

Procédez dès maintenant comme suit : déployez un noyau corrigé par le fournisseur s’il en existe un (RHEL 8/9/10, AlmaLinux 8, Debian 13), puis redémarrez le système. Le correctif KernelCare sans redémarrage est encore en phase de test et n’a pas encore été intégré à aucun dépôt ; ne comptez donc pas dessus. En attendant de pouvoir appliquer le correctif, empêchez le chargement de act_pedit si vous n’utilisez pas les règles tc pedit, et/ou restreignez les espaces de noms des utilisateurs non privilégiés. Vous trouverez ci-dessous les commandes à utiliser et les compromis à accepter.

La version longue

CVE-2026-46331 est une autre faille de corruption du cache de pages sous Linux qui transforme une erreur d'écriture du noyau en une voie d'accès pratique permettant d'obtenir les privilèges root en local. Elle se situe dans le sous-système de contrôle du trafic, plus précisément dans l'action d'édition de paquets `act_pedit` que `tc` utilise pour réécrire les octets d'en-tête des paquets en transit.

Ce qui est inquiétant, ce n'est pas seulement le bug. C'est la manière dont il a été découvert.

Le correctif en amont a fait l'objet d'une discussion publique en tant que correction d'une corruption de données, sans numéro CVE ni présentation évidente sous l'angle de la sécurité. Le CVE a été attribué plus tard, lors de la fusion le 16 juin, et un PoC public exploitable a suivi le lendemain. Cela fait de « pedit COW » un « N-day » au sens où l'entendent les défenseurs : les détails techniques exploitables étaient visibles sur une liste de diffusion publique avant que la plupart des équipes ne disposent d'un CVE, d'une règle de scanner, d'un avis de fournisseur ou d'un processus de correctif associé.

Nous n'avons pas détecté cette faille grâce à notre propre système de surveillance. Elle nous a été signalée par un client via une escalade ; elle n'a jamais été mentionnée sur oss-security, et le flux CNA du noyau ne figure pas actuellement sur notre liste de surveillance. Cette lacune est en soi une leçon à tirer concernant les bogues du noyau pour lesquels on privilégie la correction immédiate avant l'attribution d'un numéro CVE, et c'est l'une des raisons pour lesquelles cet article a été rédigé.

Suis-je concerné ?

Considérer un hôte comme exposé si toutes les conditions suivantes sont remplies :

• Le noyau contient la branche de code `act_pedit` vulnérable.
• Le module act_pedit est chargé ou peut être chargé automatiquement à la demande.
• Les espaces de noms des utilisateurs non privilégiés sont activés, ce qui confère à un attaquant le droit CAP_NET_ADMIN au niveau de l'espace de noms, dont l'exploit a besoin.
• Un utilisateur local non fiable ou partiellement fiable peut exécuter du code sur la machine.

act_pedit se charge automatiquement dès qu'une action « pedit tc » est configurée ; par conséquent, un lsmod vide ne signifie pas pour autant que tout est en ordre, contrairement à ce que l'on pourrait croire. Vérifiez bien les trois conditions suivantes :

# Is the module loaded right now?
lsmod | grep -w act_pedit

# Can it be loaded on demand?
modinfo act_pedit 2>/dev/null | head -n 1

# Are unprivileged user namespaces available?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

Vous pouvez également vérifier si vous utilisez réellement cette action : la commande `tc actions list action pedit` renvoie un résultat vide sur les hôtes qui n'exécutent pas de règles `pedit` à l'heure actuelle. Un résultat vide ne garantit pas votre sécurité — un attaquant capable d'insérer une règle depuis l'intérieur d'un espace de noms peut toujours accéder au chemin d'exécution — mais cela vous indique si la mesure de protection recommandée, à savoir la liste noire de modules, peut être appliquée en toute sécurité.

Sous RHEL et Debian, l'userns non privilégié est ouvert par défaut. Sous Ubuntu, il est contrôlé par les paramètres du noyau `kernel.apparmor_restrict_unprivileged_userns` / `_unconfined`, mais ce contrôle est une mesure de renforcement de la sécurité, et non un correctif du noyau : le PoC le contourne à l'aide d'une astuce `aa-exec` sur la version 24.04. Ubuntu 26.04 renvoie un « FAIL » face au PoC pour la même raison liée à AppArmor, tandis que le noyau sous-jacent reste vulnérable.

Qu'est-ce que « pedit COW » ?

« pedit » est l'abréviation de « packet editor » (éditeur de paquets) : il s'agit d'une action de contrôle du trafic qui permet aux administrateurs de réécrire les champs des en-têtes de paquets lorsque ceux-ci transitent par des filtres et des actions tc configurés. La fonction vulnérable est tcf_pedit_act(), située dans le fichier net/sched/act_pedit.c.

Ce problème appartient à la même famille que « Dirty Pipe », « Copy Fail » et « Dirty Frag » : une routine du noyau écrit dans une page dont elle n'a pas la propriété exclusive, et cette écriture aboutit dans une entrée du cache de pages correspondant à un fichier sur le disque. La nouveauté réside ici dans le point de déclenchement. Au lieu d'un chemin rapide de cryptage ou d'un chemin de décryptage sans copie, le déclencheur est une action de modification de paquet qu'un processus non privilégié peut configurer depuis l'intérieur d'un espace de noms utilisateur.

D’un point de vue général, le bogue provient du calcul trop précoce de la plage de paquets modifiables. Avant de modifier les données d’un paquet, le noyau appelle la fonction `skb_ensure_writable()` pour rendre les octets cibles privés. La fonction `tcf_pedit_act()` calculait cette plage une seule fois, avant la boucle sur les clés d’édition, en utilisant une valeur pré-calculée appelée `tcfp_off_max_hint`. Cette valeur indicative ne tenait pas compte du décalage d’en-tête à l’exécution ajouté par les clés de type : ces clés déterminent leurs décalages par rapport aux en-têtes L2/L3/L4 au moment de l’exécution, de sorte que le décalage d’écriture réel n’est connu qu’une fois la boucle lancée. Une partie de la destination n’est donc jamais rendue privée. Il s’agit là d’une copie partielle à l’écriture (copy-on-write), et l’écriture dans la région non soumise à la copie à l’écriture constitue une écriture hors limites, traversant plusieurs pages.

Étant donné que le SKB peut faire référence à des pages sans copie (zero-copy) récupérées via la fonction `sendfile`, cette écriture hors limites peut se retrouver dans la mémoire partagée du cache de pages correspondant à un fichier réel. Le noyau estime avoir sécurisé la mémoire du paquet pour permettre sa modification ; en réalité, l'écriture ultérieure dépasse les limites de la région qu'il a effectivement privatisée.

Comment fonctionne réellement cette faille

Le PoC public (sgkdev/packet_edit_meme) enchaîne quatre éléments courants – l'action `act_pedit`, des tampons de socket pouvant référencer des pages « zero-copy », des espaces de noms utilisateur non privilégiés et le cache de pages – et ne nécessite ni « heap shaping » ni « race window ».

1. Espace de noms et capacité. À partir d’un espace de noms d’utilisateur sans privilèges, l’attaquant obtient la capacité CAP_NET_ADMIN au niveau local de cet espace de noms, ce qui lui suffit pour configurer des actions de contrôle du trafic au sein de l’espace de noms qu’il contrôle.
2. Liaison de contrôle du trafic. Ils configurent une action « pedit » avec des clés typées dont le décalage d'exécution se situe en dehors de la plage rendue accessible en écriture par la fonction `tcf_pedit_act()`, ce qui déclenche l'écriture COW partielle.
3. Ciblage du cache de page. En injectant des références de fichiers « zero-copy » dans la pile réseau, ils visent à provoquer une écriture hors limites dans l'image ELF mise en cache du fichier /bin/su exécuté avec les droits setuid-root.
4. Charge utile. Ils écrasent le point d'entrée mis en cache avec un shellcode équivalent à setgid(0), setuid(0) et execve(« /bin/sh »).
5. Root. Ils quittent l'espace de noms et exécutent la commande « su ». Le cache de pages partagé fournit l'image corrompue, et le shellcode s'exécute en tant que root.

Le fichier binaire sur le disque ne change jamais. La corruption n’existe que dans le cache de pages, ce qui explique pourquoi l’analyse de hachage des fichiers et l’analyse forensic du disque peuvent ne rien révéler alors qu’un shell root est déjà ouvert. La seule condition préalable qui importe concerne les espaces de noms d’utilisateurs non privilégiés dotés du droit CAP_NET_ADMIN – ouverts par défaut sous RHEL et Debian, mais soumis à des restrictions sous Ubuntu.

Ce que modifie le correctif en amont

Le correctif fusionné (objet : « net/sched : act_pedit : étendre la plage SKB inscriptible par clé ») restructure le chemin COW afin que la plage inscriptible suive le décalage réel :

• Cela déplace la fonction `skb_ensure_writable()` à l'intérieur de la boucle par clé, là où le décalage d'écriture réel est connu.
• Cela ajoute une vérification de débordement pour les opérations arithmétiques sur les décalages et protège la fonction `offset_valid()` contre la valeur `INT_MIN`, pour laquelle la négation n'est pas définie.
• Pour les décalages négatifs – par exemple, les modifications de l'en-tête Ethernet à l'entrée –, il utilise plutôt la fonction skb_cow() pour appliquer le principe COW à la marge.
• Cela permet de linéariser dès le départ les blocs SKB contenant des fragments partagés, de sorte qu'une page « zéro copie » ne puisse pas être corrompue à l'insu de l'utilisateur.

Il s'agit d'une modification autonome portant sur une seule fonction. Le correctif « rebootless » de KernelCare est un portage fidèle de ce correctif en amont, plutôt qu'un équivalent « kpatch » conservateur : il reconstruit le chemin COW à l'intérieur de la fonction tcf_pedit_act() en utilisant la même logique skb_ensure_writable() / skb_cow() par clé et les mêmes contrôles de décalage.

Pourquoi ce bug passait facilement inaperçu

« pedit-cow » n'a jamais été signalé aux responsables de la sécurité comme une faille d'urgence spécifique. Il semblait s'agir d'un correctif visant à résoudre un problème de corruption de données réseau, et c'est ainsi qu'il a été intégré dans l'arborescence.

Cela a son importance car la plupart des processus de correction surveillent les flux CVE, les avis des éditeurs, le canal « oss-security » et les mises à jour des scanners. Dans ce cas précis, les implications en matière de sécurité ne sont apparues qu’ultérieurement : le correctif a d’abord été identifié, le CVE a été publié au moment de la fusion, puis la preuve de concept (PoC) a suivi dans la journée. Pour les failles du noyau de cette catégorie, l’approche consistant à « corriger d’abord, publier le CVE ensuite » ouvre une fenêtre pendant laquelle les attaquants et les chercheurs spécialisés peuvent déterminer si la faille est exploitable avant même que les processus de correction habituels des entreprises n’aient pris connaissance du problème.

Conclusion pratique : considérez les correctifs publics du noyau concernant la corruption du cache de pages, le COW partiel, les écritures sans copie et la gestion des plages SKB inscriptibles comme potentiellement liés à la sécurité avant même l'apparition d'un CVE ou d'un PoC.

Qui est concerné ?

La vulnérabilité dépend de trois facteurs : la possibilité de charger act_pedit, l'autorisation accordée aux utilisateurs non privilégiés et la présence ou non d'un noyau corrigé dans votre distribution.

Exploitable confirmé par une démonstration de concept (PoC) publique (vérifiée par l'auteur, sans privilèges root) :

• RHEL 10.0 sur 6.12.0-228.el10 – aucun indicateur n'est nécessaire ; les comptes utilisateurs sont ouverts par défaut
• Debian 13 trixie sur 6.12.90+deb13.1 – aucun indicateur requis
• Ubuntu 24.04.4 sur 6.17.0-22 – nécessite le contournement « –ubuntu aa-exec userns »

Ubuntu 26.04 (7.0.0-14) renvoie « FAIL », mais cela est dû au renforcement de la sécurité des utilisateurs par AppArmor, et non à une correction du noyau. Le noyau sous-jacent reste vulnérable.

Correction fournie par le fournisseur (déployer le noyau corrigé et redémarrer) :

• RHEL 10 – RHSA-2026:27288
• RHEL 9 – RHSA-2026:27789
• RHEL 8 – RHSA-2026:27353 ; la version recompilée pour AlmaLinux 8 porte le numéro ALSA-2026:27353 (publiée le 22 juin). RHSA-2026:27355 correspond à la variante 8.8 EUS/TUS.
• Debian 13 trixie – DSA-6355-1 (publié le 21 juin)

Sans oublier la branche principale et les backports stables.

Problèmes identifiés mais non encore résolus par les éditeurs: les serveurs pour lesquels la seule solution disponible à ce jour est une mesure d’atténuation provisoire, et pour lesquels la couverture des correctifs sans redémarrage revêtira une importance capitale dès leur publication :

• Debian 11 et 12
• Ubuntu Bionic jusqu'à Noble (la version 24.04.4 est une cible confirmée pour le PoC)

Non concerné ou toujours ouvert :

• RHEL 7 / CentOS 7 – non concernées.
• Oracle UEK 6 et UEK 7 – statut « ouvert » dans notre fil de discussion dédié au développement.

Agir dès maintenant

La solution la plus sûre consiste à protéger immédiatement le noyau en cours d'exécution. Il existe trois moyens concrets d'y parvenir, classés par ordre de préférence.

1. Correctif ou correctif sans redémarrage

Installez le noyau corrigé par le fournisseur, s'il existe, et redémarrez dès que cela est techniquement possible. Donnez la priorité aux hôtes sur lesquels s'exécute du code partiellement non fiable : nœuds Kubernetes, exécuteurs CI/CD, hébergements partagés, systèmes de développement et de compilation, plateformes multi-locataires et hôtes de conteneurs acceptant des charges de travail non fiables.

Les correctifs KernelCare sans redémarrage pour la vulnérabilité CVE-2026-46331 sont en cours de développement et de test par rapport au correctif en amont. D'après le dernier état de la couverture, rien n'a encore été publié dans les flux « test », « main » ou « ePortal ». Dès qu'une version est disponible, vérifiez-la :

kcarectl --patch-info | grep -i 'CVE-2026-46331'
kcarectl --info | grep kpatch-build-time      # build dated on or after the release

2. Bloquez la fonction act_pedit si vous ne l'utilisez pas

act_pedit se charge automatiquement dès qu'une action « pedit tc » est configurée. Si vous n'utilisez aucune règle « tc pedit » (ce qui est le cas de la plupart des hôtes), empêchez-le de se charger.

Le bulletin de Red Hat (RHSB-2026-008) recommande la mise en place d'une liste noire au démarrage :

echo 'blacklist act_pedit' > /etc/modprobe.d/blacklist-act-pedit.conf

Une liste noire empêche uniquement le chargement automatique au démarrage. Étant donné qu’act_pedit peut être chargé automatiquement à la demande dès qu’une règle y fait référence, la méthode la plus fiable consiste à modifier la configuration lors de l’installation pour pointer le module vers /bin/true :

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

Vérifiez ensuite si elle est chargée et ne la déchargez que si aucune règle de trafic active ne dépend d'elle :

lsmod | grep -w act_pedit && sudo rmmod act_pedit
lsmod | grep -w act_pedit || echo "act_pedit not loaded"

Pour annuler la modification, supprimez le fichier :

sudo rm /etc/modprobe.d/disable-act_pedit.conf

Rayon d'action : toute configuration de contrôle du trafic utilisant l'action « pedit » échouera à se charger tant que le blocage sera actif. Certaines configurations de conteneurs/CNI et de qualité de service (QoS) en dépendent ; par conséquent, n'appliquez pas cette mesure sur les hôtes qui ont besoin de règles « tc pedit ». Vérifiez à l'aide de la commande « tc actions list action pedit » avant de procéder à un déploiement à grande échelle.

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

L'exploit nécessite un espace de noms utilisateur sans privilèges pour obtenir le droit CAP_NET_ADMIN au niveau de cet espace de noms. La fermeture des espaces de noms utilisateur sans privilèges rompt la chaîne publique, quel que soit l'état du module.

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

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

Sous Ubuntu, vous pouvez plutôt renforcer les contrôles AppArmor existants (kernel.apparmor_restrict_unprivileged_userns / _unconfined), ce qui permet de bloquer d'emblée le PoC sur la version 26.04.

Remarque concernant la compatibilité : les espaces de noms utilisateur sans privilèges sont requis par les environnements d'exécution de conteneurs sans root, plusieurs sandbox d'intégration continue (CI), la fonction unshare(1) sans privilèges, les navigateurs en mode sandbox et Flatpak. Acceptable sur les charges de travail renforcées ou d'hébergement, mais perturbant sur les hôtes de développement et de conteneurs. Tester avant tout déploiement à grande échelle.

Le moment décisif

Si l'hôte n'applique aucune règle tc pedit → bloquez act_pedit ; c'est la modification la plus restrictive. S'il a besoin de pedit mais pas de conteneurs sans root ni de unshare sans privilèges → restreignez plutôt les utilisateurs. S'il a besoin des deux → un patch ou un patch sans redémarrage est la seule véritable solution ; isolez l'exécution locale non fiable jusqu'à ce moment-là.

Correctif sans redémarrage KernelCare

Situation au 23 juin 2026, 18 h 30 UTC : en phase de test active dans le cadre du ticket principal KCARE-27230. Aucune version n'est encore disponible sur les canaux test, main ou ePortal. Le suivi des travaux par distribution est assuré sous les tickets KCARE-27167 (EL10), KCARE-27223 (EL9), KCARE-27159 (EL8) et KCARE-27204 (Debian 13).

Dès qu'une version est disponible dans le flux de test, appliquez-la à l'aide de la commande suivante :

kcarectl --update --prefix test

Une fois validée, elle sera disponible lors de la prochaine exécution programmée, ou vous pouvez la récupérer à la demande :

kcarectl --update

Vérifier :

kcarectl --patch-info | grep -i 'CVE-2026-46331'

Détection

Il n'existe aucune signature fiable permettant de détecter une compromission de « pedit-cow ». La corruption se trouve dans le cache des pages ; le fichier binaire sur le disque reste intact, et les traces disparaissent dès que les pages mises en cache sont évacuées ou que le système redémarre. Les contrôles d'intégrité des fichiers ne constituent pas un indicateur fiable dans ce cas.

Les signaux comportementaux qui méritent d'être repérés :

• Le module act_pedit se charge de manière inattendue sur les hôtes qui n'utilisent pas l'édition de paquets pour le contrôle du trafic.
• Activité tc inhabituelle de la part d'utilisateurs ou de processus qui ne configurent normalement jamais le réseau.
• Création d'espaces de noms d'utilisateurs sans privilèges peu avant l'exécution d'un binaire setuid.
• l'exécution de commandes « su », « sudo » ou dans le shell à la suite d'une opération de contrôle du trafic sans motif légitime.

Suivi de l'exécution des commandes « tc » et du chargement des modules :

auditctl -w /sbin/tc -p x -k tc_exec
auditctl -w /usr/sbin/tc -p x -k tc_exec
grep act_pedit /proc/modules

Si vous soupçonnez une exploitation, videz le cache de la page pour forcer le rechargement des octets d'origine à partir du disque :

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

Considérez cela comme une mesure de confinement, et non comme une remédiation. Si un attaquant a déjà obtenu les privilèges root, l'expulsion ne supprime pas la persistance qu'il a mise en place par la suite. Tout hôte sur lequel un utilisateur local non fiable a eu accès à un shell pendant la période d'exposition doit être considéré comme potentiellement compromis.

Pourquoi les bugs comme « pedit-cow » reviennent sans cesse

Les problèmes « pedit-cow », « Dirty Pipe », « Copy Fail » et « Dirty Frag » diffèrent dans les détails, mais partagent un point commun : un chemin rapide axé sur les performances qui repose sur une hypothèse erronée quant à la sécurité d’écriture d’une page. Dans chaque cas, une écriture a atteint une page que le noyau croyait lui appartenir, et le cache de pages en a fait les frais car il est partagé par conception : chaque lecteur d’un fichier voit la même page physique, de sorte qu’une seule écriture incorrecte sur celle-ci peut devenir visible pour un code privilégié lisant des octets exécutables.

Ces failles sont dangereuses précisément parce qu’elles transforment une « corruption de mémoire locale » en une menace concrète. Un attaquant n’a pas besoin de contourner les droits d’accès aux fichiers ni de modifier quoi que ce soit sur le disque. Il lui suffit de corrompre la copie mise en cache suffisamment longtemps pour qu’un code privilégié puisse la lire ou l’exécuter.

La solution à long terme ne consiste pas à « cesser d’optimiser ». Il s’agit plutôt de renforcer les garanties de propriété des pages tout au long des chemins de gestion de la mémoire du noyau – un travail de longue haleine, car cela touche les parties du noyau les plus sensibles aux performances. pedit-cow ne sera pas le dernier bug de cette famille. Cela montre également pourquoi il est de plus en plus difficile d’apporter une réponse le jour même : une vulnérabilité peut passer d’un correctif d’apparence ordinaire à un CVE, puis à un exploit root public avant que de nombreuses organisations n’aient une vision claire de leur situation opérationnelle.

Liste de contrôle des mesures correctives prioritaires

1. Correctif. Déployez le noyau corrigé par l'éditeur (RHEL 8/9/10, AlmaLinux 8, Debian 13) puis redémarrez le système. N'attendez pas le correctif KernelCare ne nécessitant pas de redémarrage : il n'est encore disponible dans aucun dépôt.
2. Appliquez des mesures d'atténuation là où vous ne pouvez pas installer de correctif. Bloquez `act_pedit` si vous n'appliquez aucune règle `tc pedit`, ou limitez les utilisateurs non privilégiés si vous en avez la possibilité.
3. Vérifiez les accès locaux. Identifiez les utilisateurs disposant d'un accès shell sur les hébergeurs partagés, les environnements d'exécution CI/CD, les serveurs de compilation et les systèmes multi-locataires. Retirez les autorisations qui ne sont pas nécessaires pendant cette période.
4. Rechercher. Appliquer les heuristiques de détection à la période d'exposition, en commençant par le message publié sur la liste de diffusion fin mai.
5. Redémarrez après l'application du correctif. Cela permet d'effacer toutes les pages mises en cache potentiellement corrompues, ainsi que l'ancien noyau.

Références

• NVD – CVE-2026-46331 : https://nvd.nist.gov/vuln/detail/CVE-2026-46331
• Fiche CVE.org – CVE-2026-46331
• Avis GitHub GHSA-cr2w-747q-47qc
• Red Hat RHSB-2026-008 – Élévation de privilèges liée au contrôle du trafic, et la page CVE de Red Hat
• Errata du fournisseur : RHSA-2026:27288 (RHEL 10), RHSA-2026:27789 (RHEL 9), RHSA-2026:27353 (RHEL 8 = AlmaLinux ALSA-2026:27353 ; RHSA-2026:27355 correspond à la variante 8.8 EUS/TUS), DSA-6355-1 (Debian 13)
• Suivi de sécurité Debian – CVE-2026-46331
• Démonstration publique de faisabilité (Massimiliano Oldani, 17 juin 2026) : https://github.com/sgkdev/packet_edit_meme
• Fil de discussion netdev : miroirs LKML v2 et v3 ; racine du fil sur Spinics
• Stable fix commits (git.kernel.org/stable/c/<hash>): 899ee91156e5, 2bec122b9fb9, 3dee9d0c198f, b198ed4e5258
• Suivi KernelCare : dossier général KCARE-27230 ; correctif sans redémarrage CL Gerrit 256818 ; par distribution KCARE-27167 / 27223 / 27159 / 27204

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.

Pour en savoir plus sur KernelCare, cliquez ici →