Noyau Linux : ZDI-CAN-33367 permet de modifier des fichiers en lecture seule (famille Dirty Frag), preuve de concept publique
Un utilisateur local peut altérer le cache de fichiers en lecture seule (su, etc.) et devenir root ; code d'exploitation public, pas encore de CVE. AlmaLinux a des noyaux corrigés en test, Debian rien au 24/10 : bloquer esp4/esp6 si IPsec n'est pas utilisé.
par Frédéric Vagner · publié le
- Sévérité
- Haute CVSS 7,8 / 10
- Produits
- DebianAlmaLinuxNoyau Linux
- Versions touchées
- Noyau Linux avec skb_zerocopy() sans le marqueur SHARED_FRAG (AlmaLinux 8, 9, 10 confirmés)
- Versions corrigées
- AlmaLinux (testing) : 4.18.0-553.177.2.el8_10, 5.14.0-687.59.2.el9_8, 6.12.0-211.68.2.el10_2 ; Debian : en attente
- Correctif
- Contournement seulement
- Source
- almalinux.org ↗
Une nouvelle faille du noyau Linux, suivie par la Zero Day Initiative de Trend Micro sous le nom ZDI-CAN-33367, permet à un utilisateur local sans privilège de modifier le contenu en mémoire (cache de pages) de fichiers qu'il peut seulement lire, par exemple /usr/bin/su. Elle a été signalée le 21/10/2026 aux listes publiques du noyau avec le code d'une preuve de concept fonctionnelle. C'est la même famille que Dirty Frag et Fragnesia, par un autre chemin du code réseau.
Qui est concerné ?
Tous les serveurs Linux où des utilisateurs non fiables peuvent obtenir un shell : hébergement mutualisé, builds de conteneurs, runners CI, comptes SSH clients. AlmaLinux 8, 9 et 10 sont confirmés vulnérables par l'équipe AlmaLinux ; la preuve de concept utilise un espace de noms utilisateur non privilégié (activé par défaut sur AlmaLinux) et les modules IPsec esp4 / esp6. Pour Debian 12 et 13 et Proxmox : aucun correctif annoncé au 24/10/2026 (dernier DSA noyau : DSA-6568-1 du 16/10, sans rapport) ; l'exposition est à confirmer.
Risque
CVSS 7,8 (élévation de privilèges locale, évaluation ZDI). Le bug est dans skb_zerocopy() (utilisé par NFQUEUE et Open vSwitch) : il conserve les pages d'un fichier mais perd le marqueur SKBFL_SHARED_FRAG, si bien que le déchiffrement IPsec ESP écrit directement sur le cache du fichier. Le fichier sur le disque n'est pas modifié, mais tous les processus voient les octets de l'attaquant jusqu'à l'éviction du cache ou au redémarrage. Aucun identifiant CVE n'est encore attribué et aucune exploitation active n'est confirmée à ce jour (absent du catalogue CISA KEV).
Corriger
Correctif amont : « net: skbuff: propagate shared-frag marker in skb_zerocopy() » (liste netdev, 22/10/2026). AlmaLinux a rétroporté le correctif sans attendre Red Hat ; les noyaux sont dans le dépôt testing (pas encore en production au 24/10) :
- AlmaLinux 8 :
kernel-4.18.0-553.177.2.el8_10 - AlmaLinux 9 :
kernel-5.14.0-687.59.2.el9_8 - AlmaLinux 10 :
kernel-6.12.0-211.68.2.el10_2
sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
# après redémarrage : désactiver le dépôt de test
sudo dnf config-manager --disable almalinux-testing
uname -rSur Debian et Proxmox : surveiller le tracker (security-tracker.debian.org/tracker/source-package/linux) et appliquer le noyau dès sa publication.
Contournement
Bloquer les modules IPsec ESP (sans effet sur un système qui n'utilise pas IPsec ; à ne pas faire si vous utilisez IPsec, les tunnels cesseraient de fonctionner) :
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/zdi-can-33367.conf; rmmod esp4 esp6 2>/dev/null; true"
lsmod | grep -E '^esp(4|6)' # aucune ligne = contournement actifSi vous soupçonnez une attaque avant la mise en place du contournement, vider le cache de pages (echo 3 > /proc/sys/vm/drop_caches en root) ; seul un redémarrage sur le noyau corrigé garantit l'élimination de toute altération.
Vérifier
uname -r
rpm -q kernel # AlmaLinux
dpkg -l 'linux-image*' # DebianVoir aussi le suivi PwnEscape (article sur CVE-2026-99999) pour les noyaux Debian et AlmaLinux.