Dirty Frag (CVE-2026-43284, CVE-2026-43500) : publication des correctifs KernelCare Live

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

Une semaine après la découverte de Copy Fail (CVE-2026-31431), le chercheur Hyunwoo Kim a révélé une deuxième faille permettant l'escalade locale des privilèges dans le noyau Linux, touchant le même domaine général (IPsec ESP et rxrpc), qu'il a baptisée Dirty Frag. Une preuve de concept publique et fonctionnelle existe. Tout utilisateur local non privilégié peut l'utiliser pour obtenir les droits root en une seule commande.

L'équipe technique de KernelCare a publié des correctifs en direct pour l'ensemble de la famille de noyaux EL8 dans les 24 heures suivant la divulgation, avant même la publication des errata correspondants par les éditeurs, EL9, Ubuntu, Debian et Proxmox VE ayant suivi dans la même vague de mises à jour. Le correctif s'applique au noyau en cours d'exécution et prend effet sans redémarrage.

Un deuxième exploit rendu public, baptisé «Copy Fail 2 : Electric Boogaloo », fait référence à cette même vulnérabilité sous ce pseudonyme. Il n'existe pas de numéro CVE distinct pour « Copy Fail 2 ». Toutes les informations contenues dans cet avis s'appliquent.

Contexte: démonstration de concept publique et compte rendu · publication sur oss-security · entrée NVD pour CVE-2026-43284 · correctif en amont

Pourquoi c'est urgent

La faille réside dans le chemin de déchiffrement en place des modules esp4, esp6 et rxrpc. Lorsque le chemin de réception déchiffre des tampons paginés n'appartenant pas au noyau (par exemple, des pages de canal atteignant le socket via splice(2) / sendfile(2)), des processus non privilégiés peuvent conserver des références au texte en clair résultant, ce qui permet d'effectuer une opération d'écriture dans le cache de pages que le PoC public transforme en privilèges root en une seule commande.

L'embargo sur la divulgation responsable a été levé le 7 mai 2026 avant que les distributeurs aient pu se coordonner. Un exploit fonctionnel a été rendu public avant l'attribution des identifiants CVE et avant que les errata des éditeurs ne soient prêts. Sur tout système où des utilisateurs non privilégiés peuvent exécuter du code, cette situation doit être traitée comme un incident nécessitant une mise à jour le jour même.

Le point sur l'attribution des CVE :

La vulnérabilité liée à l'écriture dans le cache de pages de xfrm-ESP est référencée sous le numéro CVE-2026-43284.
La vulnérabilité d'écriture dans le cache de pages de rxrpc porte le numéro CVE-2026-43500 (enregistrement dans la base NVD en attente).

Correctifs en temps réel KernelCare : disponibles dès maintenant, sans redémarrage

KernelCare a fourni des correctifs en temps réel avant la publication des errata des éditeurs pour toutes les distributions prises en charge :

Famille EL8 (RHEL 8, CentOS 8, Oracle Linux 8, CloudLinux 8, CloudLinux 7 Hybrid, AlmaLinux 8, Rocky Linux 8)
Famille EL9 (RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9)
Ubuntu 22.04 LTS (Jammy), y compris les versions AWS et HWE
Debian 12 (Bookworm)
Proxmox VE 7 (noyau 5.15) et Proxmox VE 8

Les clients recevront automatiquement le correctif lors de leur prochaine exécution de la commande `kcarectl –update`.

Les ELS pour les noyaux FIPS sont également pris en charge

Les noyaux certifiés FIPS de TuxCare pour AlmaLinux 9.2 et 9.6, bénéficiant du support à vie (ELS), ont été corrigés. Les clients ELS-FIPS recevront le correctif via le même canal de distribution KernelCare (versions K20260508_20 et K20260508_19 respectivement) sans qu'aucune action supplémentaire ne soit requise.

Ce que les clients de KernelCare doivent faire

Dans la plupart des cas, rien ne se passe. Si la mise à jour automatique de kcarectl est activée (c'est le réglage par défaut), le correctif est récupéré et appliqué lors de la prochaine interrogation planifiée. Pour l'appliquer immédiatement :

kcarectl --update

Comment vérifier que vous disposez bien des derniers correctifs

Vérifiez la date de compilation du correctif chargé :

kcarectl --info | grep kpatch-build-time

Tout correctif daté du 8 mai 2026 ou d'une date ultérieure contient le correctif. Pour vérifier à l'aide de la référence CVE :

kcarectl --patch-info | grep -i 'CVE-2026-43284\|CVE-2026-43500\|dirty.frag\|xfrm'

La chaîne de caractères indiquant la version du noyau renvoyée par la commande `uname -r` ne change pas avec KernelCare, car le noyau en cours d'exécution est corrigé en mémoire plutôt que remplacé sur le disque.

Solution provisoire (si vous ne pouvez pas effectuer la mise à jour immédiatement)

Si l'application du correctif en direct KernelCare n'est pas possible pour le moment, ajoutez les modules esp4, esp6 et rxrpc à la liste noire afin qu'ils ne puissent pas être chargés, et déchargez-les s'ils sont déjà présents :

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

Pour revenir en arrière après l'application du correctif en direct :

sudo rm /etc/modprobe.d/dirtyfrag.conf

Compatibilité : esp4 et esp6 sont les transformations ESP côté noyau utilisées par IPsec. Leur désactivation perturbe les tunnels IPsec qui s'appuient sur le chemin de données du noyau sur la machine concernée. N'appliquez pas cette mesure corrective sur les hôtes qui terminent ou transitent des tunnels IPsec, strongSwan ou Libreswan. rxrpc est le transport AF_RXRPC utilisé presque exclusivement par les clients AFS et n'est pas présent sur les serveurs d'hébergement web classiques.

Restaurer les fichiers binaires du cache de page après l'application des mesures correctives

Cette faille permet de modifier des binaires système légitimes présents dans le cache de pages dans le cadre de l'obtention des privilèges root ; par conséquent, la mise en place de la mesure de protection ne suffit pas à elle seule sur les systèmes qui auraient pu être ciblés avant sa mise en place. Une fois la mesure de protection appliquée, videz le cache de pages :

echo 3 | sudo tee /proc/sys/vm/drop_caches

Liens

Vous n'utilisez pas encore KernelCare ?

KernelCare fournit des correctifs en temps réel pour les vulnérabilités CVE du noyau aux systèmes en cours d'exécution, sans redémarrage ni fenêtre de maintenance. Le même modèle de déploiement qui a permis de corriger la vulnérabilité « Dirty Frag » dans les 24 heures suivant sa divulgation publique s'appliquera désormais à toutes les vulnérabilités CVE du noyau présentant un niveau de gravité élevé.

Commencez un essai gratuit