Dirty Frag : vulnérabilité du noyau Linux et correctifs

Shared FAQ page chrome (breadcrumb, dates, read time, «Continuer la lecture», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Dernière mise à jour : 9 mai 2026

Résumé

Une vulnérabilité d'élévation de privilèges locale dans le noyau Linux, connue sous le nom Dirty Frag, a été divulguée. Elle est suivie principalement sous les références :

• CVE-2026-43284 : IPsec ESP / esp4 / esp6
• CVE-2026-43500 : RxRPC / rxrpc

Dirty Frag peut permettre à un utilisateur local non privilégié d'obtenir les privilèges root. Il ne s'agit pas d'un exploit réseau distant direct, mais la faille est sérieuse pour les serveurs d'hébergement, car un attaquant peut d'abord obtenir un accès limité via un site web compromis, un compte SSH/SFTP, une charge conteneurisée ou un compte utilisateur local. cPanel confirme que le problème touche le noyau Linux lui-même et qu'il est présent dans plusieurs distributions Linux. (cPanel Support)

---

Systèmes concernés

Dirty Frag touche plusieurs distributions Linux et branches de noyau. Les plateformes confirmées comme concernées comprennent :

• AlmaLinux 8, 9, 10
• Rocky Linux 8, 9, 10
• CloudLinux 7 Hybrid, 8, 9, 10
• Red Hat Enterprise Linux 8, 9, 10
• Ubuntu 20.04, 22.04, 24.04 et les autres versions Ubuntu prises en charge
• Les systèmes Oracle Linux utilisant des noyaux RHCK ou UEK concernés
• Les autres distributions Linux utilisant des versions de noyau concernées

CloudLinux confirme que CloudLinux 7 standard n'est pas concerné, tandis que CloudLinux 7 Hybrid, 8, 9 et 10 le sont. CloudLinux 9 et 10 utilisent la branche de noyau AlmaLinux. (Blog CloudLinux)

---

Action requise

La correction recommandée consiste à installer le noyau corrigé de l'éditeur et à redémarrer le serveur.

Vérifier le noyau actuel :

uname -r

Après la mise à jour et le redémarrage, vérifiez à nouveau :

uname -r

Installer le paquet de noyau ne suffit pas. Le serveur doit démarrer sur le noyau corrigé.

---

Instructions de mise à jour par système d'exploitation

AlmaLinux 8 / 9 / 10

Mettre le noyau à jour :

dnf clean metadata
dnf update 'kernel*' -y
reboot

Vérifier :

uname -r
rpm -q kernel

Versions corrigées attendues :

AlmaLinux 8:  kernel-4.18.0-553.123.2.el8_10 or newer
AlmaLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

AlmaLinux confirme ces versions de noyau corrigées dans son avis Dirty Frag. (AlmaLinux OS)

---

CloudLinux

CloudLinux 7 Hybrid / 8

Si le noyau corrigé est disponible dans les dépôts stables :

yum update 'kernel*' -y
reboot
uname -r

Si le noyau corrigé n'est disponible que dans le dépôt testing/beta :

Pour CloudLinux 8 :

yum --enablerepo=cloudlinux-updates-testing update 'kernel*' -y
reboot
uname -r

Pour CloudLinux 7 Hybrid :

yum --enablerepo=cl7h_beta update 'kernel*' -y
reboot
uname -r

Versions corrigées attendues :

CloudLinux 7 Hybrid: kernel-4.18.0-553.123.2.lve.el7h or newer
CloudLinux 8:        kernel-4.18.0-553.123.2.lve.el8 or newer

CloudLinux liste ces versions cibles pour les branches de noyau corrigées CL7h et CL8. (Blog CloudLinux)

---

CloudLinux 9 / 10

CloudLinux 9 et 10 utilisent la branche de noyau AlmaLinux. Si le noyau corrigé est disponible dans les dépôts stables :

dnf update 'kernel*' -y
reboot
uname -r

Versions corrigées attendues :

CloudLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

Si le noyau corrigé n'est pas encore visible depuis les dépôts stables ou les miroirs locaux, utilisez temporairement le dépôt testing d'AlmaLinux.

Pour CloudLinux 10 :

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
dnf update 'kernel*' -y
reboot

Après le redémarrage :

uname -r
dnf config-manager --disable almalinux-testing

Pour CloudLinux 9 :

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm
dnf update 'kernel*' -y
reboot

Après le redémarrage :

uname -r
dnf config-manager --disable almalinux-testing

N'utilisez le dépôt testing que pour mettre à jour les paquets de noyau, puis désactivez-le immédiatement après vérification. CloudLinux documente ce passage temporaire par le dépôt testing pour CL9 et CL10. (Blog CloudLinux)

---

RHEL / Rocky Linux / Oracle Linux

Pour les systèmes de la famille RHEL :

dnf clean all
dnf update 'kernel*' -y
reboot

Pour les systèmes Oracle Linux utilisant UEK, mettez aussi à jour les paquets UEK :

dnf update 'kernel*' 'kernel-uek*' -y
reboot

Vérifier :

uname -r
rpm -q kernel kernel-core kernel-uek 2>/dev/null

Red Hat confirme que Dirty Frag touche RHEL 8, 9, 10 et OpenShift 4, et recommande la mise à jour du noyau ou la mesure de contournement selon la disponibilité du correctif. (Portail client Red Hat)

---

Ubuntu / Debian

Mettre le noyau du système à jour :

apt update
apt full-upgrade -y
reboot

Vérifier :

uname -r
dpkg -l | grep linux-image

Ubuntu confirme que le correctif est livré via les paquets d'image du noyau Linux et recommande de redémarrer sur le noyau mis à jour. (Ubuntu)

---

SUSE / openSUSE

Mettre le noyau à jour :

zypper refresh
zypper update kernel-default
reboot

Vérifier :

uname -r
rpm -qa | grep kernel

---

Mesure de contournement temporaire

Si aucun noyau corrigé ni correctif à chaud n'est encore disponible, bloquez les modules concernés :

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

rmmod esp4 esp6 rxrpc 2>/dev/null || true

Vérifier :

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Cette mesure bloque esp4, esp6 et rxrpc, qui sont les chemins de modules du noyau concernés. CloudLinux, Ubuntu et Red Hat documentent tous cette approche de blocage des modules comme mesure de contournement temporaire. (Blog CloudLinux)

---

Avertissement important

N'appliquez pas cette mesure sans examen préalable sur les systèmes utilisant :

• IPsec
• StrongSwan
• Libreswan
• des passerelles VPN
• des charges AFS / RxRPC

Bloquer esp4 et esp6 peut interrompre le trafic IPsec, et bloquer rxrpc peut affecter les charges AFS/RxRPC. Ubuntu et Red Hat signalent tous deux cet impact opérationnel. (Ubuntu)

---

Étape supplémentaire Ubuntu / Debian

Sur les systèmes Ubuntu et Debian, régénérez l'initramfs après avoir appliqué la mesure :

update-initramfs -u -k all

Puis vérifiez à nouveau :

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Ubuntu recommande de régénérer l'initramfs afin que les modules concernés restent bloqués au démarrage. (Ubuntu)

---

Vider le cache de pages après la mesure

Après avoir appliqué la mesure, videz le cache de pages :

sync
echo 3 > /proc/sys/vm/drop_caches

CloudLinux note que l'exploit peut modifier des binaires système légitimes dans le cache de pages ; vider ce cache est donc recommandé après la mesure sur les systèmes potentiellement visés. (Blog CloudLinux)

---

Retirer la mesure après le correctif

Une fois le noyau corrigé installé et le serveur redémarré dessus :

rm -f /etc/modprobe.d/dirtyfrag.conf

Pour Ubuntu / Debian :

update-initramfs -u -k all

Redémarrez si nécessaire :

reboot

---

KernelCare

Si KernelCare est installé :

kcarectl --update

Vérifier la couverture :

kcarectl --patch-info | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag'

Si la CVE n'apparaît pas dans la sortie, KernelCare ne couvre peut-être pas encore le noyau en cours d'exécution. Dans ce cas, appliquez la mise à jour du noyau de l'éditeur ou la mesure de contournement temporaire. cPanel et CloudLinux citent tous deux KernelCare comme voie de correctif à chaud lorsque la couverture existe. (cPanel Support)

---

Liste de vérification

Exécutez ce qui suit après le correctif ou la mesure de contournement :

cat /etc/os-release
uname -r

Pour les systèmes de la famille RHEL :

rpm -q kernel kernel-core kernel-uek 2>/dev/null

Pour Ubuntu / Debian :

dpkg -l | grep linux-image

Vérifier les modules concernés :

lsmod | grep -E 'esp4|esp6|rxrpc'

Confirmer l'état de la mesure :

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

---

Recommandation d'EuroVPS

Restreignez les accès SSH, SFTP, shell et panneau de contrôle inutiles, passez le serveur en revue à la recherche de sites web compromis, d'utilisateurs locaux inattendus ou d'élévations de privilèges, et migrez les systèmes d'exploitation en fin de vie.

---

Besoin d'aide ?

Ouvrez un ticket de support depuis l'espace client et, sur les serveurs où nous disposons d'un accès root, nos ingénieurs appliqueront le correctif ou la mesure de contournement et vérifieront la correction.